Community
Participate
Working Groups
Build Identifier: I20100608-0911 When debugging a program with a large share library linked over a remote target, the program takes some time to be load the share library. During this loading period if I have the Disassembly view opened it will throw NPE with below trace: java.lang.NullPointerException at org.eclipse.cdt.debug.internal.ui.disassembly.dsf.DisassemblyBackendCdi.setDebugContext(DisassemblyBackendCdi.java:132) at org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyPart.updateDebugContext(DisassemblyPart.java:1798) at org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyView $1.selectionChanged(DisassemblyView.java:66) at org.eclipse.ui.internal.AbstractPartSelectionTracker $1.run(AbstractPartSelectionTracker.java:119) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.runtime.Platform.run(Platform.java:888) at org.eclipse.ui.internal.AbstractPartSelectionTracker.fireSelection(AbstractPartSelectionTracker.java:117) at org.eclipse.ui.internal.PagePartSelectionTracker $1.selectionChanged(PagePartSelectionTracker.java:49) ...................................... Looking at org.eclipse.cdt.debug.internal.ui.disassembly.dsf.DisassemblyBackendCdi.setDebugContext(DisassemblyBackendCdi.java:132), it does a "fTargetContext.getTopStackFrame()". This function can return Null if the thread is not in suspended mode thus the stack frame is an empty list. In our case the program is in the process of loading the share library so its thread is not suspended. It's pretty re-producible with CDI. I haven't seen this problem with DSF. Reproducible: Sometimes Steps to Reproduce: 1. Create a program linking with a large shared library 2. Debug this program with CDI remote debug 3. Make sure the disassembly view is opened before you run the debug.
Created attachment 172162 [details] Fix Andy, please try this patch with your reproducible scenario. It occurred to me that the code can't really rely on the thread being suspended. All we know is that at some point in time, we had a suspended thread and one of its frames was set as the active debug context. The thread may have since been resumed, died, whatever. We can use whatever static information we can get from the frame context, but we can't assume anything else. We simply have to be more guarded in that logic.
Created attachment 172194 [details] Fix for NPE when getting frame address Another NPE caused by thread going into run mode is when getting frame address.
Toni, please review these patches. I've committed my patch to HEAD and cdt_7_0. Teo, I'll leave the commit if your patch to you since you now have commit rights! :-) I reviewed it and it looks good to me.
*** cdt cvs genie on behalf of jcortell *** Bug 317226: Disassembly view throws NPE when debugging with CDI [*] DisassemblyBackendCdi.java 1.11 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/disassembly/dsf/DisassemblyBackendCdi.java?root=Tools_Project&r1=1.10&r2=1.11 [*] DisassemblyBackendCdi.java 1.10.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/disassembly/dsf/DisassemblyBackendCdi.java?root=Tools_Project&r1=1.10&r2=1.10.2.1
*** cdt cvs genie on behalf of tmadan *** Bug 317226: Disassembly view throws NPE when debugging with CDI. Fix also NPE when getting frame address [*] CDIDisassemblyRetrieval.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/disassembly/dsf/CDIDisassemblyRetrieval.java?root=Tools_Project&r1=1.3&r2=1.4
commited my patch to HEAD and cdt_7_0. And marked as rezolved
*** cdt cvs genie on behalf of tmadan *** Bug 317226: Disassembly view throws NPE when debugging with CDI. Fix also NPE when getting frame address [*] CDIDisassemblyRetrieval.java 1.3.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/disassembly/dsf/CDIDisassemblyRetrieval.java?root=Tools_Project&r1=1.3&r2=1.3.2.1
*** Bug 314268 has been marked as a duplicate of this bug. ***
- Sorry for the delay, John. Yes I re-tested using my custom test case this problem is now fixed. Thanks for taking it.
*** Bug 320018 has been marked as a duplicate of this bug. ***
Reviewed.
