Skip to main content

[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

Andy, I'm going to investigate this some more and will hopefully have a plan of action. Technically, one could say any method that returns a reference could theoretically (some day, some way) return null. Should every such call have a null pointer check after it? I'll side-step that mine field for now and just say I'll keep working on this to get this resolved :-)


At 12:04 PM 6/17/2010, Andy Jin wrote:
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?


-----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


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.


At 10:54 AM 6/17/2010, Andy Jin wrote:
>When debugging a program with a large share library linked over a
>target, the program takes some time to be load the share library.
>this loading period if I have the Disassembly view opened it will throw
>NPE with below trace:
>at org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyView
>at org.eclipse.ui.internal.AbstractPartSelectionTracker
>at org.eclipse.ui.internal.PagePartSelectionTracker
>Looking at
>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
>Is it simply a miss to check for Null condition or is it something
>deeper in the code?
>cdt-dev mailing list

cdt-dev mailing list
cdt-dev mailing list

Back to the top