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.
Summary: | NullPointerException at org.netbeans.modules.cnd.debugger.gdb.proxy.GdbProxyEngine$CommandInfo.access$100 | ||
---|---|---|---|
Product: | cnd | Reporter: | Egor Ushakov <gorrus> |
Component: | Debugger | Assignee: | _ gordonp <gordonp> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | avp, blaha |
Priority: | P1 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://statistics.netbeans.org/exceptions/detail.do?id=28621 | ||
Issue Type: | DEFECT | Exception Reporter: | 28621 |
Attachments: |
gdb log
full log |
Description
Egor Ushakov
2008-08-05 09:42:56 UTC
Please attach full gdb-log more recent log: java.lang.NullPointerException 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) seems like it was fixed already reproduced again, see http://statistics.netbeans.org/analytics/detail.do?id=132990 Created attachment 72676 [details]
gdb log
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. 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 isn't it a showstopper? Could you please describe user visible consequences? 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. 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. Is it stopper for RC2 or the bug can be delivered in FCS? I believe it should be fixed in FCS. see also issue #151481 Another simple solution may be to make GdbProxyEngine.sendCommand synhronized. 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 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?
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. 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). Forgot the changeset ID: http://hg.netbeans.org/main?cmd=changeset;node=13de38c43b7b now in the same conditions in trunk I get: java.util.ConcurrentModificationException 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: java.lang.NullPointerException 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 Created attachment 72736 [details]
full log
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. verified in incremental local build #121 Code changed reviewed and approved. Reopened and marked with 65_HR_FIX keyword to follow the Code Freeze Process Fixed in release65 with http://hg.netbeans.org/release65?cmd=changeset;node=6a52853827ee verified in a preliminary FCS build (NetBeans IDE 6.5 RC2 (Build 200811010001)) |