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.

Bug 166146 - ruby debugging fails on V3 prelude B28D
Summary: ruby debugging fails on V3 prelude B28D
Status: VERIFIED FIXED
Alias: None
Product: ruby
Classification: Unclassified
Component: Debugger (show other bugs)
Version: 6.x
Hardware: Sun All
: P1 blocker (vote)
Assignee: _ pcw
URL:
Keywords:
Depends on:
Blocks: 166049
  Show dependency tree
 
Reported: 2009-05-28 02:20 UTC by _ pcw
Modified: 2009-06-15 11:09 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
patch to fix stack trace bug. (1.21 KB, text/plain)
2009-06-09 02:57 UTC, _ pcw
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ pcw 2009-05-28 02:20:20 UTC
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.
Comment 1 _ pcw 2009-05-28 02:21:23 UTC
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.
Comment 2 _ pcw 2009-06-06 04:52:47 UTC
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.
Comment 3 _ pcw 2009-06-08 05:13:54 UTC
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.
Comment 4 _ pcw 2009-06-08 05:14:22 UTC
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.
Comment 5 _ pcw 2009-06-08 19:56:32 UTC
Reference to glassfish tracking issue.

https://glassfish.dev.java.net/issues/show_bug.cgi?id=8486
Comment 6 _ pcw 2009-06-09 02:56:06 UTC
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.
Comment 7 _ pcw 2009-06-09 02:57:23 UTC
Created attachment 83337 [details]
patch to fix stack trace bug.
Comment 8 Vince Kraemer 2009-06-09 22:30:46 UTC
the attached patch is safe.
Comment 9 Quality Engineering 2009-06-11 08:57:00 UTC
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.
Comment 10 Michal Mocnak 2009-06-11 14:13:19 UTC
Verified in nb6.7 rc3 build #200906100001 with gf3 b28e 06-10-2009.
Comment 11 _ pcw 2009-06-11 19:33:50 UTC
Raising priority to P1 - management authorized respin of V3 Prelude and deemed debugging a must fix feature for release.
Comment 12 _ pcw 2009-06-11 19:35:30 UTC
Pushed to release67 branch.
Comment 13 _ pcw 2009-06-11 19:38:15 UTC
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).
Comment 14 Martin Schovanek 2009-06-15 11:09:12 UTC
Verified in 6.7RC3 build by QE.