SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: kwilliams on July 14, 2021, 12:28:47 AM
-
Hi,
I have a Scala project that I want to debug. When I select Debug -> Attach Debugger -> Attach to Java Virtual Machine, nothing happens. I expected a dialog to ask for remote debugging information like the port.
-
I'm assuming you've got the SBT project you mentioned in another post open.
It should pop up a modal dialog when you select that. And it looks like if there's an error before then, it should pop up a message box. Very strange.
Can you still type in the editor window after that? Is there any output in the "Build" tool window? If you try it again, look in the status bar at the bottom left, is there any message there?
If you're on Linux, what window manager are you using?
-
Thanks for responding.
It turns out that I did not have my JDK configured in the SlickEdit project. So now, I get a pop-up that say: "could not find a 'tool.jar' for your configured JDK.".
I am using OpenJDK 11. Searching around, it sounds like OpenJdk may have moved things around a bit. The contents of tools.jar, rt.jar and a couple other have been moved to different jar files.
It sounds like Slickedit would need to update to account for this unless there is some way to tell it to look somewhere else.
-
Tools.jar got repackaged for Java 1.9 I think. The debugger code should account for that, and it works for me on OpenJDK 11.0.11. I suspect the version comparison, it's got a lot of cases from dealing with the version conventions of different JDK providers over the years, so there may be some corner case it's failing on that I'm not seeing.
What's the output you get for "java --version" on your system? And if you go into the Tools -> Options dialog, and go to Languages -> Application Languages -> Java -> Compiler Properties, what's in the "Compiler Name" pulldown?
-
My Java version is Amazon Corretto-11.0.6 and compiler name is JDK 11.0.6
-
I can reproduce with JDK as well. Taking a look at it, it should be hot-fixable.
-
Awesome!
thanks for looking into this.
-
The fix for this will be in the next 25.0.2 hotfix.
-
I applied the hotfix, but now I get “Error waiting for pydbgp connection: Socket timed out†(which is weird because I tried to attach to a java jvm and pydbg is a Python debugger).
It’s waiting for a connection on 127.0.0.1:55151.
I using the following menu: “Debug->Attach-Debugger->Attach to Java Virtual Machineâ€
I confirmed that I could attach to the VM with the JDB command line.
Am I doing it wrong?
Here is the text of the dbg.xml file:
<debug>
<logging v="0"/>
<setJDWPEnvironment v="0"/>
<jdwpHost v="127.0.0.1"/>
<jdwpPort v="5006"/>
<idePort v="55151"/>
<workingDir v="C:\Code\MI\7.5Exp\EnGen\Client\Library\"/>
</debug>
In subsequent attempts the attach dialog would not come up, even after restart.
btw, I'm running Windows 10.
Thank you.
Kurt
-
Hmm, the "pydbgp" reference is a UI mistake from sharing some of the setup UI, it's using the right protocol underneath.
Nothing looks obviously wrong with the dbg.xml. With a timeout like that, it sounds like something that could have prevented the debuggee from connecting back to our debugger. If the debuggee had died, we would pick up on that before a full timeout.
We can enable some debug logging. Restart SlickEdit, go to the SlickEdit command line and type in "set-var def-debug-logging 2", and then try to attach the debugger. This will produce some output in the Build window. (and if it gets far enough, also some output will go into your configuration directory under logs/debug.log. On windows, the default configuration directory is under Documents\My SlickEdit Config. You can also see it in the Help -> About dialog).
Post the output from those two places. And afterwards, run "set-var def-debug-logging 0", it's a persistent setting and can build up a large set of logs pretty fast.
It probably doesn't matter, but what version of SBT are you using?
-
Thanks for getting back to me.
I'm using SBT 1.4.7
I set the logging variable but I'm not seeing logs (I saw user.cfg.xml update with the set-var command).
I currently can't get the attach dialog to come up. Maybe I need to re-install?
<edit>
I re-installed but the "Attach to Java Virtual Machine" dialog does not come up when I select it. Others do (like "Debug Java Program")
-
In theory, you should either get an error dialog at this point, or the attach dialog, so I'm not sure why you don't get anything. It does sound odd, if you go to the SlickEdit command line and just run scala-attach, do you get a dialog?
You shouldn't need to re-install. The install directory is read-only, only things in the configuration directory gets changed. You can try starting with a clean config if you want to rule out a configuration problem. Go to a cmd.exe or powershell prompt, and start SlickEdit like this: c:\Program Files\SlickEdit Pro 2020\win\vs.exe -sc %TEMP%\seconfig And you can open up your project and see if you can attach then.
-
scala-attach didn't show a dialog either.
running with a clean config gave me the old "can't find tools.jar" so I had to apply the hotfix. Then I was back to no attach dialog.
also nothing is logged when I use 'set-var def_debug_logging 2' as far as I can tell.
-
So not even any output in the Build window?
I'll trace through the codepath again, maybe I missed some way for you to get nothing.
-
nope. nothing. I tried again just to be sure. the build window was empty.
there doesn't seem to be any indication that the set-var command did anything (other than what showed up the the user.cfg.xml). Is there a get?
I tried some other debug related actions to see if any of those would induce a log message but so far nothing.
-
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.
-
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.
-
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.
-
It looks like the error is on line 1312. the call to 'CheckLatestJDK'?
-
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.
-
according to help --> about, I have hotifx_se2502_3_cumulative.zip (revision 3)
-
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.
-
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"
-
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?
-
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
-
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.
-
PM sent to your Inbox Kurt.
Best,
SlickEdit Support
-
Thanks!
see debug.log attached
-
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.
-
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
-
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.
-
Yes!
Thank you!
Looking forward to trying it out
-
PM sent.
SlickEdit Support
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
ok. I'll be in the office again tomorrow. I'll test again and stop the debugger first.
-
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.
-
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.
-
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).
-
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
-
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.
-
sounds good. I'll grab the jar and run another test in the morning.
-
Here are the new logs. Thanks for fixing the nulls in the logging. That made it a lot easier.
-
That did it, I can reproduce it with the information from that log. I've followed it enough to determine it's not going to be a quick fix confined to the backend, so there won't be a updated download today at least.
Thanks for sending in those logs.
-
awesome!
I'll wait to here from you then.
Thanks!
-
Ok, I've updated the vsdebug.dll and the jar file. You can download and re-apply those, and it should be able to hit the breakpoints.
-
Ok. I'll give it a try.
-
Ok, now when I attempt to place a breakpoint, I get: "Error enabling breakpoint: DBGP error: Parse error in command".
When I click OK in the error pop-up, my breakpoint is disabled.
I've attached the usual logs.
-
That's unexpected, it means we don't have a package + class associated with the breakpoint locations. We use the tagging information to fill that out. I do need to fix it to give a better error for this before the debugger tries to attach, having a package + class (or just class for the main module with no package statement) is required to set the breakpoints reliably for Scala.
For that project, in standard edit mode (not the debugger) run "toggle-breakpoints" in the SlickEdit command line to bring up the breakpoints window. Are there any breakpoints that have empty "Class" columns? If you use F9 to get rid of and then re-add the breakpoint with an empty Class column at the same location, does the class field get populated? If you go to that location in the editor window, does the "Current context" widget that's probably at the top of your editor (unless you removed it via View -> Toolbars) show any package + class, or is it blank?
If the tagging really isn't marking a class/package for that location, we'll need to debug the tagging to see why that is, either by getting a high level idea of where the breakpoints are set (ie, "in the body of a Seq.map that's in a object method"), or getting some sort of example that can reproduce a place where a breakpoint can't be set.
-
yep, the class is empty for any breakpoints I set in that file. breakpoints in another file in the project seem to fill in the class.
-
Are these breakpoints in a method, or on a property initialization in a class or object somewhere? Or somewhere else I'm not considering?
For the files I have tried so far, the only place I can get a blank Class for the breakpoint is trying to set one outside of a object/class/method body. There may be a error parsing your file that's leaving us with no class/package information for that line, but I can't see that without an example that reproduces it. That's why I'm trying to get a general idea of what sort of Scala statements are around your breakpoint lines.
One other way to narrow it down would be to delete pieces of the code before the breakpoint in one of the problem files, take out whole vars or methods at a time. After each one, use F9 to clear and re-set the breakpoint. If it comes back with the Class field populated, than the parser is likely having problems with the last thing you deleted, and then we can figure out if you can PM that snippet or a (sanitized version with identifier names changed) to me so I can try to track down the problem from there.
-
they were in a try block inside a future.
it looked a little like this:
Future { blocking { try { <breakpoints in here> } catch {...} } }
-
Ok. So if I do a skeleton of that layout inside a method like the following, I it works, so I think we're parsing the overall structure correctly. Here's the actual snippet I put in an existing function:
val f = Future { blocking {
try {
do_something()
} catch {
case Bad() => ()
}
} }
Messing around with adding bad syntax to this to this, I can get it to fail to set a breakpoint either by putting bad syntax in the body of the try, or in the body of the catch. So in this case is is possible code coming after the breakpoint can cause it to fail the parse, if we fail in the catch body.
So more blind divide and conquer - remove the body of the catch block, does the breakpoint resolve a class when you toggle it then? If so, put it back, and remove catch clauses until you get to clause that changes the behavior. And then, it's either the destructuring in the catch clause, or something in the body of the clause, and we can go from there.
If clearing the catch clause doesn't make it go away, start removing statements in the try body, before the breakpoint until the breakpoint can resolve, and we can drill down into the last statement you deleted before it started working.
-
Ok. I'll try that and see what I find. It may take me a bit. I have my hair on fire right now with a high priority task.
More to follow.
-
Just got back in to test this and discovered that my trial expired :(
-
New trial license on the way; check your Inbox :)
Best,
SlickEdit Support
-
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.
-
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.
-
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.
-
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.
-
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.
-
Awesome!
I'll wait to hear from you.
-
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.
-
Sounds good!
I re-installed and it said my license was invalid though.
Kurt
-
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?
-
Looks like it is expired.
-
New license on the way; check your inbox.
Best,
SlickEdit Support
-
Got it, Thanks!
but now I get a socket timeout again. Do I need to re-apply the last patch?
-
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.
-
Yes, Build date is Oct 18, 2021. State file: July 23.
Attached are the debug.log and the build window just in case
-
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.
-
That gave me a different result. It looks like I was able to attach. The debug windows came up and I was able to pause and see a call stack. but all of my attempts to set a breakpoint resulted in "Unable to set breakpoint at this location: Could not find the specified function".
-
Trying to narrow it down. This may sound ridiculous, but if you detach, set the breakpoint at that location, and attach, does it stop at the breakpoint at all?
-
I've been trying the debugger with some different codebases than what I usually test with, and I see that breakpoint message with a location in SBT. My changes for checking the stepping speed and locals had a few more rough edges that I wanted, so there are also some issues I see related to that and not inherent in the real fix. Like double clicking on a call stack location to go to that location not always working. (even though a breakpoint at that location would locate the file). Feel free to uninstall the test install, and put back the regular one.
This isn't hot-fixable, which is why I've been having to send jars and installers. I'm working on getting these in for 26.0.1, which will come out before the end of the year.
-
Ok, thanks.
I tried playing around with it some more. It's been timing out and failing to connect.
I'll wait to hear from you.
We're pretty eager to move to SlickEdit, so let me know if you have something to test or need more info.
-
I think the last debug logs with timeouts we got, it was the one where it was started with some of the old code still running with your regular config, so I don't think that's the same problem.
If you can reproduce it without too much trouble, you can clear the debug.log, set the def-debug-logging var, and gather the debug.log and send it. And the output in the Build window, though there shouldn't be much there with the updated installer.
Without the logs I'm assuming it's in the borderline timeout territory because of the problem where it gathers too much information on connect. That's definitely on the list to fix for the point release.
-
Hi Patrick,
any word on releasing a fix for this?
-
Not yet. I had planned for it to be in 26.0.1, but we ran into other issues that ate into my time. So I'm tentatively aiming for 26.0.2.
-
The fixes for this did go in to 26.0.2. Some notes:
1) The attach should be faster, I reorganized some of the initialization code whose time was linear with the number of classes the JVM has loaded. There still is a linear dependency, this just greatly reduces the constant factor associated with the setup.
2) The problems with breakpoints and file prompts related to the directory structure not matching the package should be gone now.
3) Should no longer see mangled names for some closure parameters.