Attach to Virtual Machine not working

[patrick]

Just a quick update, I've found and fixed the problem with the attach.  I did have to make some changes to a protocol used by multiple debuggers, so I've still got some testing to finish up. Once that's done, there will be a jar file and a DLL file to update to apply the fix.

[kwilliams]

Yes!

Thank you!

Looking forward to trying it out

[SlickEdit Support]

PM sent.

SlickEdit Support

[kwilliams]

I got the files and installed them. I was able to attach (i seems like I have to restart slick-edit for it to attach again). I got a bunch of failed attach attempts due to socket timeouts.

Once I attach, I put a breakpoint in the code and it does not get hit.

[patrick]

Hmm.  Having to restart to attach again without timeouts is strange, unless whatever is causing the breakpoint to be missed is leaving the listener in a bad state.

I think the only thing to do is reproduce with the logging on.  Go ahead and restart SlickEdit if you haven't already, go to the SlickEdit command prompt and type in "set-var def-debug-logging 1" and then attach and do what you did before.  After it fails to hit the breakpoint, wait at least 30 seconds (to outlive any timeouts that might log extra information), and then Debug -> Stop Debugging.  There are two logs.  One is the output in the build window, which you can copy and paste out to a file.  The other will be under My Documents\My SlickEdit Config\25.0.2\logs\debug.log.   I don't think they'll exceed the attachment size limit for the forum, but it might not hurt to zip them up before posting.

Afterwards "set-var def-debug-logging 0" again, because it's a persistent over restarts, and can eat up drive space quickly.

[kwilliams]

The good new it I think the failure to attach was user error. I think I was running my app without the debug settings so the JVM was not listening for a debugger.

Attached are my logs after setting a breakpoint.

[patrick]

Taking a look.  The output from the build window looks short - did it get cut off?  Or maybe the rest of the output was buffered until the debugger ended, and didn't make it to the build window until the debugger ended.

From the debug.log, I can see some of the set breakpoints commands timing out waiting for a response.  Sort of, it looks like we got "breakpoint set" responses about 2sec after we asked for them after we had moved on, so maybe they got set, hard to tell without the rest of the build window log.  I am not sure why it would take that long to set a breakpoint, I need to look at that code next to see what could block that. 

[kwilliams]

I thought I selected all in that window, I'll try it again and see if I get a better log in the build window.

[patrick]

No problem.  I should have remembered to mentioned that the debugger needs to be stopped before collecting the log from the Build window.  Both the backend and the Build window itself do enough buffering where a surprising amount of the logs can be in limbo until the backend quits.

[kwilliams]

ok. I'll be in the office again tomorrow. I'll test again and stop the debugger first.

[kwilliams]

Ok.

I got some new logs attached. The reason the last one was so short is that there is a weird character after the "command:" traces that appears to be interpreted as end of file or end of string (null?). I had to edit those out in the build window and then I could copy and paste it all.

Also, I am able to attach every time but it takes the full 30 second "waiting for pydgb count down". Not a major issue on my end but I thought it might be interesting.

[patrick]

That makes sense.  I was dealing with that log entirely in SlickEdit, so I didn't run into that.  I should  remap that char in the logging. I just need to know the terminator char is there, I don't need to see it.

Thanks for getting the logs, it answer a lot of my questions from the debug.log.  The breakpoints are being deferred as if the JVM hadn't loaded the classes the breakpoints are set in yet.  Which isn't impossible, I can't say how likely that is for your target program.  But I don't see the breakpoints getting resolved as the program runs, so I'm suspicious that the breakpoints are being incorrectly deferred.  Or we've missed the load events.   So I don't know what's up yet, but this gives me a couple areas of the code to look at.

[kwilliams]

Interesting. We do some late loading of classes that are defined in plugins, but the place where I put the breakpoint was in a core piece of the program that I'm certain is loaded (or else it wouldn't be working).

[kwilliams]

Also maybe of note is that we do not do a fat-jar. there are many jars that comprise the program and we use the jar file directories in the class-path

[patrick]

I haven't found anything wrong with the deferral code.  I mixed it up, trying debugging some different programs on Windows, using the different JDKs, but wasn't able to reproduce it either.

So I've had to settle on adding some more logging in a couple of places.  I'm only logging extra information for the files you had breakpoints set in before, otherwise we'd be swamped.  So use the same breakpoints as before if you can, doesn't matter if they're on the same lines or not, just that they're in the same .scala files.  And I fixed the logging so there won't be nulls in the Build window output anymore, so you won't have to do any extra steps with that output.   So:

1) Re-download the se-scala-debugger-assembly-1.0.0.jar from the link you got the updated one from, and copy it over the one in the install directory under resource/tools/scaladbgp
2) set def-debug-logging to 1 again.
3) Reproduce like you did before, with breakpoints in the same files, attaching, and waiting at least 30 seconds before ending the debug session.
4) We only need the output from the Build window, don't need the debug.log anymore.

This should give me the only bit of information I'm missing from the previous logs to decide how the deferral bug is happening.