RE: [cdt-dev] Disassembly view throws NPE when debugging with CDI

["Madan Teodor-TEMADAN1" <TEMADAN1@xxxxxxxxxxxxx>]

I have noticed this as well with our custom CDI debugger during some
test automations. Could you file a bug? 

Teo

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Andy Jin
Sent: Thursday, June 17, 2010 8:04 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Disassembly view throws NPE when debugging with
CDI

Hi, John,

Thanks for the reply. I agree that this looks strange and I only can
re-produce it with this special program linking a large shared library.
I can't re-produce it with a simply "Hello World" so I agree this is
some race condition here.

The disassembly view still shows correct content after the program is
stopped (threads are suspended).

It's not easy to debug this because if I stop at a breakpoint I am not
fast enough to capture the states of the thread before it is refreshed.
But I see it always happens at thread number 1 which (I believe) it's
still at the running mode.

After all, when we call a function which threaten to return NULL
shouldn't we at least check for it?

Thanks,
Andy

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of John Cortell
Sent: June 17, 2010 12:17 PM
To: CDT General developers list.; cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Disassembly view throws NPE when debugging with
CDI

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?

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.updat
eDebugContext(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(Abst
ractPartSelectionTracker.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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev