[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Disassembly view throws NPE when debugging with CDI
|
On 06/17/2010 09:17 AM, John Cortell wrote:
Andy,
Something strange is going on. Notice that the code to get the top
stack frame only executes if the new context is a stack frame. So, how
is it that we are being given a stack frame as the new context but
that frame's thread isn't suspended?
When stepping, a thread's frames are shown in DV but technically the
thread is running.
Cheers,
Pawel
On the surface, it looks like a bug somewhere else--a race condition
or some incoherent state. If you could figure out a way to rig the CDT
code to duplicate what's happening for you, and provide that as a
patch, that would allow us to reproduce it and investigate further.
John
At 10:54 AM 6/17/2010, Andy Jin wrote:
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.
Is it simply a miss to check for Null condition or is it something
deeper in the code?
Thanks,
Andy
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev