Attach to Virtual Machine not working

[patrick]

If you type in "set-var def-debug-logging" like that without any value, it will prompt for a value and show the current value. 

It may be just be failing too soon for anything to be logged, so don't spend much time trying to get something out of it.  I'm still looking to see if there's some path for it to fail without showing a dialog when scala-attach runs. 

[patrick]

I think I found a place where getting an error when looking at the configured java compilers can cause a silent failure.

Save the attached scala.e file and then go to Macro -> Load Module and load it.  And then try running scala-attach at the command line again, and see if you get a message box with a message and error code.

[kwilliams]

when I load the module, I get: "Expecting procedure name - identifier not found - import may be required".

I tried scala-attach anyway but still no pop-up or message in build-window.

confirmed the the def-debug-looging var is getting set.

[kwilliams]

It looks like the error is on line 1312. the call to 'CheckLatestJDK'?

[patrick]

That's odd, is the latest 25.0.2 hotfix still loaded?  That function didn't exist in base 25.0.2, but it was added in the last hotfix with the version fix.  You can look in Help -> About and see what hotfix is applied.

[kwilliams]

according to help --> about, I have hotifx_se2502_3_cumulative.zip (revision 3)

[patrick]

I made the mistake of trying it on a build of that hotfix branch rather than a 25.0.2 + hotfix package, the loading include path is a little different, which seems to be the problem here.

Download the attached .ex file, and put it in the same directory you put the scala.e you downloaded earlier.  And then try the load command again.  Let me know if it still doesn't load.   

[kwilliams]

Ok. I got a little farther. Upon module load, I get a "Slick-C Error" pop-up that says "Invalid pointer argument, file=Subject.ex offset=430" with a call-stack (attached).

If I ignore that and try a scala-attach, I get: "refactor error? -7500"

[patrick]

Ok, for the purposes of debugging, we can ignore the pointer exception.  I'll address that in the fix that I have to do anyway because of the missing error dialog.  It can only occur when manually loading scala.e when the editor has already loaded a scala project or file.  Go ahead and restart the editor so we don't have to worry about fallout from that. 

The error code is strange, because it indicates we asked for information on an invalid JDK name.  But the name we're asking for is the one it returns as the active configuration earlier.  If you look in Tools -> Options -> Languages -> Application Languages -> Java -> Compiler Properties, does your JDK show up in the list, and does the information look right?

In your configuration directory ($HOME/.slickedit/25.0.2 for Linux, "My Documents\My SlickEdit Config\25.0.2" on windows), can you get the users.cfg.xml and compilers.xml file, and post them?

[kwilliams]

Progress:
The compiler was not set, I thought I had it set before but maybe it got reset to defaults somehow?. That was part of the problem. I'm still getting the connection timeout error but lots of output in the build window.

attached are the compilers.xml, user.cfg.xml and a the build-window-output when the connection timeout happens.

Also, my trial expires tomorrow. That last thing I need working for us to migrate from VS-code to SlickEdit is the debugger. Is there any way to extend the trial? Otherwise I might be able to get approval to buy a single license for now.

Thanks again.

Kurt

[patrick]

I can't answer the trial question, but I forwarded it to someone who can.

I've only started looking through the Build window log.  Can you check to see if there's a debug.log in the configuration directory, under logs?  Gotten far enough this time there might be a log there this time.  And if not, that narrows the possibilities. 

[SlickEdit Support]

PM sent to your Inbox Kurt.

Best,
SlickEdit Support

[kwilliams]

Thanks!

see debug.log attached

[patrick]

Thanks for the logs.  I got enough information from the logs so that I can reproduce it most of the time.  Very odd, the debugging backend is attached to the JVM running scala, but something is going wrong where it never connects to the "UI" part of debugging that we host, so it times out.  And there seems to be a bad socket handle mixed in there somewhere.

I'll update once I have some sort of fix you can apply.

[kwilliams]

that's good. non-reproducable issues are the worst. I think I tried this with the firewall disabled just in case.

Let me know if you need anything from me.

Kurt