This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version: NetBeans IDE Dev (Build 20080303151112) Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\Tomas\.netbeans\dev javase distro, ruby bits from update center ------------ - bundled jruby, no changes to ruby platform were made - created rails project, did not setup any DB connection - created some foo controller, placed a breakpoint there - ran debugger - once webrick booted, tried to finish session (x button in output win) - session is not finished even after ide exit, java process has to be killed from Task manager the same for simple ruby application... Martine,i hope Jruby 1.1RC contains fix for similar problem we were facing on windows some time ago, so that it is not a duplicate of my own old issue?!:-)
I'm not sure what's the problem. Might be I've fixed it only for classic debugger. This time you are using new JRuby fast debugger. Will have to try on Windows (on Linux it works).
I am able to finish debugger session when I use "Finish Debugger Session" action. But I must admit there is some serious problem with WEBrick. My use case is: - create Rails project - start debugger and wait until the welcome page is shown in browser - finish debugger session (Shift+F5). Debugger session is finished but WEBrick java process is alive and its memory consumption is constantly increasing. Also it is not possible to stop WEBrick from IDE. Product Version: NetBeans IDE Dev (Build 20080310023444) Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
Those are two separate issue. The one Tomas found is in NetBeans. I have some workaround in my head. Likely for 6.1, not sure. It's a different issue than issue 113007 - here it is the stop button, not Finish action. Strange we did not catch it there. The one Jirka found is likely problem with JRuby's IO.select low level function. I'll try to prove so and come with some simpler scenario for JRuby team. Both pretty ugly, since they are Windows specific ;), thus time consuming for me. At least culprit seems to be known.
I've committed first part: f7bc6c44b9cb When the 'Stop button' is hit for in-debug-mode process, do the same as the session would be finished with 'Finish Debugger Session' menu item. So problem with running through JRuby's jruby.bat wrapper should gone completely. But still you get consumption-memory problem described by Jirka (likely in JRuby).
I'm playing with JRuby 1.1 RC3 and it seems that the issue with memory-consumption has gone. But I'm hitting another issue where likely Webrick somehow catching the 'exit!' method which we emits from the inside of debugger's (ruby-debug-ide) guts. So the process still stays live (but at least do not eat the memory). Just now I can't check it with native Ruby on Windows machine. On Linux it works, so might be not Webrick issue, might be JRuby's another one. In the meantime if anybody could verify that the stop button works when using Fast Debugger and *native* Ruby on Windows would be appreciated.
Yes, the stop button works when using Fast Debugger and *native* Ruby on Windows.
Likely the JRuby issue (http://jira.codehaus.org/browse/JRUBY-2315) is the culprit.
Jirka just reproduced the issue with JRuby 1.1 FCS. So still there. But we have also tried from CLI and reproducible as well. This is not bug in NetBeans. This is either bug in the debugger backend, but likely rather in the JRuby itself. The one filed before was just found by accident and is not related (or might be it is if this is resolved). I would like to have this fixed in the NetBeans 6.1 time-frame. But it is not a P1 NetBeans issue. So not sure if there is a politically correct way. If not we might bring it as an update. Changing this to TASK (but working on it).
Filed another issue against JRuby: http://jira.codehaus.org/browse/JRUBY-2363 Hopefully finally the right culprit.
So the bug was finally fixed in the JRuby 1.1.1 (should be out soon, or might be tried with trunk). (http://jira.codehaus.org/browse/JRUBY-2363). Verification welcomed.