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.
Ruby debugging doesn't work properly against V3 Prelude (B28D respin for NB 6.7). It starts and attaches fine, but breakpoints on requests don't work. The reason is that for some reason, the thread on which the breakpoint fires is not being listed as a valid thread when the debugger requests the thread list. e.g consider the following log exerpt: FINEST [org.rubyforge.debugcommons.Util]: Received: <breakpoint file='/space/tmp/junk/RailsApplication1/app/controllers/books_controller.rb' line='16' threadId='4'> FINEST [org.rubyforge.debugcommons.RubyDebuggerProxy]: Breakpoint at /space/tmp/junk/RailsApplication1/app/controllers/books_controller.rb:16, threadId: 4 FINE [org.rubyforge.debugcommons.model.RubyDebugTarget]: udpating threads FINE [org.rubyforge.debugcommons.RubyDebuggerProxy]: Sending command debugger: th l FINEST [org.rubyforge.debugcommons.Util]: Received: <threads> FINEST [org.rubyforge.debugcommons.Util]: Received: </threads> The thread table received from the "TH L" command is empty. It should not be. I'm still debugging this. The issue is very likely JRuby bug in 1.2.0 or Bug/update required in V3 scripting backend if JRuby changed how they handle threads. I'm still investigating this to figure out the exact cause.
Since the issue is in the backend, this is more of a tracking bug. Once I find the location of the failure, I'll file an issue in the correct tracker and refer to it from here.
Not much to report yet. The way JRuby handles thread adoption has changed since 1.1.4 (NB 6.5 timeframe). There may be a bug in how it works or in how RDebug is negotiating it. I'm actively investigating this issue but it is rather tedious.
The cause of the failure is this: 1) Java native threads are not added to org.jruby.internal.runtime.ThreadService.rubyThreadMap when they are adopted by JRuby. Note that requests always handled on Java native threads in V3 (from the Grizzly thread pool). 2) When a breakpoint is hit, the debugger backend issues a "TH L" command to list the current threads so it can match up whatever thread was running at that time, which is handled by (3). 3) In the jruby-debug, org.jruby.debug.Debugger.getDebugContexts() uses RubyThread.list to list the active threads. In JRuby, this is implemented to only return members of rubyThreadMap (see (1), above) so the Grizzly worker threads are missing. 4) Even though the matching thread is not found, the worker thread is stopped anyway. Additionally, the debugger is halted and left in an essentially broken state (or something like that, this part is irrelevant -- it's broken). Observations: JRuby's behavior in (1) may be intentional (e.g. perhaps rubyThreadMap is not supposed to contain Java native threads). I willl email Charles about this. There are a couple of possible workarounds... looking at them now.
Reference to glassfish tracking issue. https://glassfish.dev.java.net/issues/show_bug.cgi?id=8486
Reference to JRuby issue: http://jira.codehaus.org/browse/JRUBY-3742 I attached a patch to the glassfish issue that works around this problem in V3. we can patch it for real in a subsequent JRuby release. Once this was working, I encountered one other blatant bug -- stack traces were not working in JRuby 1.2.0 / 1.3.0 when stopped at a breakpoint. Enabling the property jruby.debug.fullTrace=true fixes this. We also were not passing --debug to JRuby. I attached a minor patch to this issue for glassfish.jruby module to fix the tracing bug, works fine now.
Created attachment 83337 [details] patch to fix stack trace bug.
the attached patch is safe.
Integrated into 'main-golden', will be available in build *200906110201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/22bd82c54d6d User: pcw@netbeans.org Log: #166146 - ruby debugging on glassfish not working well.
Verified in nb6.7 rc3 build #200906100001 with gf3 b28e 06-10-2009.
Raising priority to P1 - management authorized respin of V3 Prelude and deemed debugging a must fix feature for release.
Pushed to release67 branch.
Note: V3 Prelude B28E is required to verify this bug. To verify, breakpoints in Rails code called on HTTP threads (e.g. inside controller actions, etc) should work properly and when the debugger is stopped between steps or at a breakpoint, the stack frame view should show the correct stack (e.g more than one frame).
Verified in 6.7RC3 build by QE.