Attach to Virtual Machine not working

[kwilliams]

Got it. Thanks!

I tried putting breakpoints in some different files that did not have as much syntactical complexity. I can't set a breakpoint anywhere. even in a simple method. I get the same "parse error in command" everywhere.

I also noticed that the application becomes unresponsive as if it is at a breakpoint.

Is this a package/scope issue? The packages do not match the file paths for this project.

Update: Somehow I got it to break. It made me locate the file I had put the breakpoint in even though the file was open in the editor and the breakpoint was shown.  The editor seemed out of sync with the debugger though because I deleted all breakpoints. I think it is because it is really slow.

I was able to step through code but it was REALLY slow and unresponsive and I could not view any variables (possibly because they were defined outside of the project in another jar file?).

I could only get it to break again sporadically.

Disabling a breakpoint gave me the error message: "Index of debugger item is out of range or invalid"

sorry for the data-dump.

[patrick]

That does sound strange.  The package/filesystem mismatch shouldn't be a problem, with the exception that it's probably the reason you were prompted for the file location.  That is a UI bug that needs to be fixed, it's essentially using the method we use with Java, where the local path will match up with packages.   But the backend knows the path to the source won't match the package path.  (that's also the reason it needs a valid package attached to a breakpoint - without that, we can pick the wrong class for breakpoints if there are several classes with the same name in different packages).

I'm not sure why it would be slow for steps.  Most of the data we fetch on breakpoints is the stack frames, so it might depend either the depth or number of locals.  The number of threads shouldn't matter unless we're pulling whole stack unnecessarily, but I'll double check that.  I'll have to test this out with some extremes and see if something is slowing down in a non-linear way that could explain the speed.

My worry is that the slowness is the reason you had the program stopped while the SlickEdit UI didn't show it as being stopped - something timed out, and maybe got the two pieces out of sync, so I want to figure out the slow behavior.  This may also explain the missing variables if we've timed out walking the stack and querying locals.   I think it's a coincidence that the missing variables were defined in another jar - at the JVM/JDI level the source of a class isn't a distinguished, and would look the same to us as any other. 

That still leaves the parsing problem that makes it so we can't resolve breakpoints at certain points in your source.  Unless I find an example of that happening, the only thing you can do on your end is some of the test edits I suggested earlier to try to narrow down what sort of statement or declaration.

So for now I'll look and see if I can reproduce the slowness.  At this point, it sounds like it was chaotic and slow enough for you to get it to stop, where I won't get a log of that for now, unless I get stumped on the performance.

[kwilliams]

Thanks Patrick.

I will try to create a small example program and experiment with some of the code patterns we use to see if I can break without the slowness so I can see better what is happening.

I'm wondering if project size has anything to do with the slowness. Our projects are pretty big. Our total Scala code size is 2-3 million loc. The project I was trying to debug is smaller but still pretty big.

[kwilliams]

I created a simple project to test with. I attached the scala source for it. I was able to set breakpoints and step through code with some weird behavior but it basically worked so maybe performance was the issue there. Below is some notes on what I found.

Breakpoints behave strangely. Breakpoints that are set before you attach sometimes do not trigger. removing them produced some strange behavior, the breakpoint would move a few lines down instead of going away. removing those would also jump around. Deleting all breakpoints and creating them after attach seems to work.

if you are running sbt in the build window, the attach command injects commands into the sbt context. this fails and you have to exit sbt. This is not too much of a problem if you're aware of it. I can run SBT from a terminal window.

If you step into a method, the IDE asks you to locate the file, which is perfect. If you cancel this, you must step out or it will keep asking

Breaking on line 27 of the attached file, I see the following:
In the Autos window:
   local variable i shows its value
        local variable stuff2 shows its contents
   Thread shows **DBGP error: Error evaluating code**

In the watches window, several times I got:
Name| Value
Error | **Thread has no stack frames**

"Add watch" in the context menu did nothing. If I try to edit the "Error" item to watch one of my local variables, I get "Error querying watch: Index of debugger item is out of range or invalid"

The last time I tried debugging I was able to watch everything defined in the for loop (which compiles to an anonymous function) but not outside of it.

I'm not sure what made Watch start working. I played with it several times and I only got it working the last one.

Hope that helps.

[patrick]

I'm looking at it.  I've found what looks like is the root cause of the unpredictable behavior.  I've only got a partial fix implemented right now, and more testing to do.  But what I have has been enough to let me run your example through SBT without any breakpoints being missed, or having missing locals or missing stack frame messages.  I've got more work to do on the fix, and then retest with large amounts of threads, classes and stack frames to confirm it's still not slow for those cases.  And chase down some related things, like why toggle-breakpoints sometimes is disabled while the debugger is active.

So I expect I'll have something for you tomorrow, and what I'll probably do is just provide it as a new installer that is 25.0.2 + these fixes.  This will let you install this version to a different location, so we don't have to keep changing your main install.

[kwilliams]

Awesome!

I'll wait to hear from you.

[patrick]

Things were a little more involved, so it took longer than I expected.  There's things left for me to do, but it's in a state where we'll be able to see if it takes care of your problems.

I PM'd you the link for a new installer.   Here are the details and caveats:

• You will need to uninstall the existing 25.0.2.  You won't lose any configuration information, but the installer won't put down more than one 25.0.2 install on Windows.
• You'll need to remove any existing breakpoints, and re-add them.  If you don't do this, you'll get some spurious dialogs asking to automatically move the breakpoints when you try to attach, and that's probably not going to work consistently with this debug installer.   I'd just run debug-clear-all-breakpoints on the SlickEdit command line, and then add them back.  You might not see the package/class in the breakpoints that we were looking at before - it shouldn't be a problem.
• There are some places where I haven't added back some support code, so at times you're going to see the occasional scala mangled name, mainly in the locals, or in some class instances.   For instance, in the example file you sent, the "stuff" local may show up in the variable display as "stuff$main1" or something similar.
• There's a delay before the first breakpoint will be hit still, but it should be less than before.  This caught me by surprise, because on Linux where I mainly tested before doing the Windows build, it's much less noticable.  The root cause is we're collecting more information from the JVM at the initial attach than we probably need to, possibly in a way that leads to more requests than necessary.  So that still needs to be addressed.
• I think before if you stopped the debugger, by default the process you attached to would continue running.  With this build, it will stop.  You'll need to use Debug -> Detach to detach the debugger and keep the JVM running.

What should work: you should be able to see the locals, breakpoints will stop the program and not get out of sync where the UI thinks it's running while the JVM is stopped.  After the initial attach delay, stepping and other debugger operations should be very fast.

[kwilliams]

Sounds good!

I re-installed and it said my license was invalid though.

Kurt

[patrick]

I double checked the installer I put out this morning, and it does work with a trial license.  What was the full name of the msi file you installed from?

Did you just get a dialog box with the invalid license message, or did the trial dialog come up before that?

[kwilliams]

Looks like it is expired.

[SlickEdit Support]

New license on the way; check your inbox.

Best,
SlickEdit Support

[kwilliams]

Got it, Thanks!

but now I get a socket timeout again. Do I need to re-apply the last patch?

[patrick]

No, don't load any of the .e files we sent before.  That could undo some of the changes made in the version we sent you. 

Just to be paranoid, if you go to Help -> About, is the build date Oct 18th?

When does the socket timeout happen?  Right after you attach?   

It may be best to just get a log.  Go to the SlickEdit command line, and "set-var def_debug_logging" to turn on the logging, delete any already existing debug.log under Documents\My SlickEdit Config\25.0.2\logs, and try to attach to reproduce the problem.  And then post the resulting ...\debug.log file.

[kwilliams]

Yes, Build date is Oct 18, 2021. State file: July 23.

Attached are the debug.log and the build window just in case

[patrick]

I see what happened, that's my fault.  The state file that's in your configuration directory has information from the loaded patches in it, and I since I didn't bump the version number for the build, SlickEdit didn't know to re-build the statefile on startup. So it was part new code and part old code running.

The easiest thing to do from here is to run with a clean configuration for this test.  Quit out of SlickEdit.   Go to a cmd.exe window, and run this to start SlickEdit with a clean configuration directory, that won't touch your real configuation: "C:\Program Files\SlickEdit Pro 25.0.2\win\vs" +new -sc "%TEMP%\TestConfig"

Re-open your project from there, and try attaching.