Bug 142889 - NullPointerException at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine$CommandInfo.access$100
NullPointerException at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyE...
Product: cnd
Classification: Unclassified
Component: Debugger
All All
: P1 (vote)
: 6.x
Assigned To: _ gordonp
Depends on:
  Show dependency treegraph
Reported: 2008-08-05 09:42 UTC by Egor Ushakov
Modified: 2009-06-25 10:59 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT

gdb log (767.20 KB, text/plain)
2008-10-27 12:13 UTC, Egor Ushakov
full log (6.84 KB, text/plain)
2008-10-28 09:31 UTC, Egor Ushakov

Note You need to log in before you can comment on or make changes to this bug.
Description Egor Ushakov 2008-08-05 09:42:56 UTC
Build: NetBeans IDE Dev (Build 200802190005)
VM: Java HotSpot(TM) 64-Bit Server VM, 1.6.0_03-b05
OS: Linux,, amd64
User comments: After I add new watches ( list.count() ) gdb try in runtime stop program and show me value
STACKTRACE: (first 10 lines)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine$CommandInfo.access$100(GdbProxyEngine.java:365)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.getCommandInfo(GdbProxyEngine.java:311)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.getCurrentToken(GdbProxyEngine.java:298)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.processMessage(GdbProxyEngine.java:243)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.access$000(GdbProxyEngine.java:71)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine$1.run(GdbProxyEngine.java:144)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986)
Comment 1 Egor Ushakov 2008-08-05 09:43:33 UTC
Please attach full gdb-log
Comment 2 Egor Ushakov 2008-08-05 10:16:38 UTC
more recent log:
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine$CommandInfo.access$100(GdbProxyEngine.java:373)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.getCommandInfo(GdbProxyEngine.java:319)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.getCurrentToken(GdbProxyEngine.java:306)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.processMessage(GdbProxyEngine.java:251)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.access$000(GdbProxyEngine.java:71)
        at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine$1.run(GdbProxyEngine.java:152)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986)
Comment 3 Egor Ushakov 2008-08-20 16:18:38 UTC
seems like it was fixed already
Comment 4 Egor Ushakov 2008-10-27 11:58:11 UTC
reproduced again, see
Comment 5 Egor Ushakov 2008-10-27 12:13:58 UTC
Created attachment 72676 [details]
gdb log
Comment 6 Egor Ushakov 2008-10-27 12:35:45 UTC
The problem is that watches are evaluated in a RequestProcessor (see GdbWatchVariable),
and thus simultaneously from many different threads (there can be 50 threads in the default RequestProcessor).
And current implementation of GdbProxyEngine is not thread safe.
Comment 7 Egor Ushakov 2008-10-27 13:27:17 UTC
Steps to reproduce on any OS:
- create many watches (the more the faster you get the error)
- do steps in debugger with watches window opened
Comment 8 Leonid Lenyashin 2008-10-27 13:55:27 UTC
isn't it a showstopper? Could you please describe user visible consequences?
Comment 9 Egor Ushakov 2008-10-27 14:07:43 UTC
Proposed "fix" for 6.5 may be to use custom made RequestProcessor with only 1 thread.
Anyway tool tip expression evaluation may still happen at the same time, so this will only decrease the failure probability.
Comment 10 Egor Ushakov 2008-10-27 14:18:09 UTC
I think this is a showstopper because debugging may fail at any time. And you have to start from the very beginning.
On my machine with OpenSolaris exception appears and current debugging session becomes broken.
Next debugging session can be started normally in both cases.
Comment 11 Petr Blaha 2008-10-27 15:04:50 UTC
Is it stopper for RC2 or the bug can be delivered in FCS?
Comment 12 Alexander Pepin 2008-10-27 15:27:39 UTC
I believe it should be fixed in FCS.
Comment 13 Alexander Pepin 2008-10-27 15:31:33 UTC
see also issue #151481
Comment 14 Egor Ushakov 2008-10-27 17:26:31 UTC
Another simple solution may be to make GdbProxyEngine.sendCommand synhronized.
Comment 15 Egor Ushakov 2008-10-27 17:46:25 UTC
I think that having synhronized GdbProxyEngine.sendCommand is a better solution than custom RequestProcessor because
custom RequestProcessor in one place can not assure that we wont use sendCommand from different places. Actually it
almost makes gdb lite thread safe, because gdb request processing is done in a single thread already.
Comment 16 _ gordonp 2008-10-27 19:19:36 UTC
> I think that having synhronized GdbProxyEngine.sendCommand is a better solution than
> custom RequestProcessor because custom RequestProcessor in one place can not assure
> that we wont use sendCommand from different places. Actually it almost makes gdb lite
> thread safe, because gdb request processing is done in a single thread already.

I'm about 90% certain that the debuggercore/viewmodel module controls threads for watch
evaluation (I was planning on checking but haven't had a chance yet). So I don't see
that as a good solution unless I'm wrong about the thread control.

As for synchronizing sendCommand, if the problem were as simple as sendCommand being
interrupted because it wasn't synchronized then I would expect to see error responses
with garbled gdb/mi commands. I looked through the gdb-log you attached and didn't see
any. Have you seen these in other gdb logs?
Comment 17 Egor Ushakov 2008-10-27 21:48:33 UTC
I believe that this issue is mainly because collection tokenList is not synchronized,
anyway we have to check every shared resource used in sendCommand, so I think that making whole sendCommand synchronized
may be acceptable solution for 6.5.
Comment 18 _ gordonp 2008-10-28 02:41:04 UTC
I've synchronized tokenList and sendCommand. I never did see the NPE after testing most of the
day, but I did get a ConcurrentModificationException on tokenList (hence its synchronization).
Comment 19 _ gordonp 2008-10-28 02:42:12 UTC
Forgot the changeset ID: http://hg.netbeans.org/main?cmd=changeset;node=13de38c43b7b
Comment 20 Egor Ushakov 2008-10-28 09:30:57 UTC
now in the same conditions in trunk I get:
	at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761)
	at java.util.LinkedList$ListItr.next(LinkedList.java:696)
	at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.getCommandInfo(GdbProxyEngine.java:403)
	at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.getCurrentToken(GdbProxyEngine.java:391)
	at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.processMessage(GdbProxyEngine.java:331)
	at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine.access$100(GdbProxyEngine.java:78)
	at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine$2.run(GdbProxyEngine.java:242)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997)

and then:

	at org.netbeans.modules.cnd.debugger.gdb.models.AbstractVariable.getValue(AbstractVariable.java:187)
	at org.netbeans.modules.cnd.debugger.gdb.models.GdbWatchVariable.getValue(GdbWatchVariable.java:180)
	at org.netbeans.modules.cnd.debugger.gdb.models.VariablesTableModel.isReadOnly(VariablesTableModel.java:131)
	at org.netbeans.spi.viewmodel.Models$DelegatingTableModel.isReadOnly(Models.java:1549)
	at org.netbeans.spi.viewmodel.Models$CompoundModel.isReadOnly(Models.java:3121)
	at org.netbeans.modules.viewmodel.TreeModelNode$MyProperty.canWrite(TreeModelNode.java:960)
	at org.netbeans.beaninfo.editors.StringEditor.attachEnv(StringEditor.java:134)
	at org.openide.explorer.propertysheet.RendererFactory.preparePropertyEditor(RendererFactory.java:326)
	at org.openide.explorer.propertysheet.RendererFactory.getRenderer(RendererFactory.java:201)
	at org.openide.explorer.propertysheet.RendererPropertyDisplayer.getRenderer(RendererPropertyDisplayer.java:293)
	at org.openide.explorer.propertysheet.RendererPropertyDisplayer.paintComponent(RendererPropertyDisplayer.java:272)

full log will be attached
Comment 21 Egor Ushakov 2008-10-28 09:31:59 UTC
Created attachment 72736 [details]
full log
Comment 22 Egor Ushakov 2008-10-28 09:43:07 UTC
fixed in: http://hg.netbeans.org/main/rev/50918f805a9a
Comment 23 Quality Engineering 2008-10-28 16:47:18 UTC
Integrated into 'main-golden', will be available in build *200810281401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/13de38c43b7b
User: Gordon Prieur <gordonp@netbeans.org>
Log: Fix for IZ #142889. I never did get the NPE but I did get a concurrent mod exception on tokenList. I tried on both Vista and Solaris with
15 watches in Quote and did several thousand (very fast:-) step intos. I synchronized GdbProxyEngine.sendCommand (like Egor suggested)
as well as tokenList (because of the CME).

Please reopen if the NPE is seen again.
Comment 24 Alexander Pepin 2008-10-28 20:52:31 UTC
verified in incremental local build #121
Comment 25 Thomas Preisler 2008-10-28 21:13:39 UTC
Code changed reviewed and approved.
Comment 26 Alexander Pepin 2008-10-29 14:30:34 UTC
Reopened and marked with 65_HR_FIX keyword to follow the Code Freeze Process 
Comment 27 _ gordonp 2008-10-29 18:03:57 UTC
Fixed in release65 with http://hg.netbeans.org/release65?cmd=changeset;node=6a52853827ee
Comment 28 dnikitin 2008-11-01 10:16:23 UTC
verified in a preliminary FCS build (NetBeans IDE 6.5 RC2 (Build 200811010001))

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo