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.
if you set a breakpoint in your Rails application (say, inside one of the models), debug the application on V3, and fire the request that would activate the code where the breakpoint is, it will appear that the debugger and the application hang. What is happening is that the breakpoint was hit and rdebug sent back conflicting thread information, specifically that the breakpoint was hit on thread X but that the current thread list only contains thread Y where X is not equal to Y. I'm investigating what could have caused this. The bug could be in either V3 or ruby-debug.
Consider the following output from the Ruby debugger and rdebug trace logs when set to maxmimum: [RailsSM] Processing output line: <breakpointAdded no="1" location="/space/tmp/ruby/simple_rails_application/app/models/item.rb:7"/> [DebugCM] Breakpoint at /space/tmp/ruby/simple_rails_application/app/models/item.rb:7, threadId: 4 [DebugCM] udpating threads [DebugCM] Sending command debugger: th l [DebugCM] WARNING Thread with id 4 was not found ... [RailsSM] Processing output line: <breakpoint file="/space/tmp/ruby/simple_rails_application/app/models/item.rb" line="7" threadId="4"/> [RailsSM] Processing output line: Stopping Thread #<Thread:0xb3f4c> [RailsSM] Processing output line: Threads equal: true [RailsSM] Processing output line: Processing: th l [RailsSM] Processing output line: <threads> [RailsSM] Processing output line: <thread id="5" status="false" /> [RailsSM] Processing output line: <thread id="5" status="false" /> [RailsSM] Processing output line: </threads> As you can see, the breakpoint was fired on thread 4, but there is no thread 4 in the list of active threads -- only a thread 5. So program breaks, but there is no way to view the active location because, well, there isn't one, hence the perceived hang.
Created attachment 65623 [details] messages.log with full debugger tracing enabled.
JRuby issue with auto-adopted threads. I have a workaround that looks good, patch pending.
JRuby issue for tracking: http://jira.codehaus.org/browse/JRUBY-2868
Should be changed to at least to TASK if not bug in NetBeans.
The work around for the JRuby issue goes into GlassFish V3 codebase and is tracked here: https://glassfish.dev.java.net/issues/show_bug.cgi?id=5390 I don't know if I agree to changing to task (what is the task?) but I will do that to get it off the NetBeans dashboard. I think we are still awaiting integration approval for commiting to V3 M1 branch (hich will be bundled with 6.5M2) but I will make sure that happens at this end.
> what is the task? Do not know formal definition. I'm using it for issues which are not actually issues in NetBeans per se, i.e. I can't fix them there, but are related and people might file duplicates against NetBeans for it. Also helps to keep to track progress when the issue in JRuby (in this case) is fixed.
The JRuby 1.1.3 bug has a work-around integrated into V3 build 18 onward and JRuby 1.1.4 fixes it (and so the workaround is removed for JRuby version > 1.1.3). Closing as fixed.