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

There is a distinction between API method and non-API method. For API
method if it says to return null we'd better respect it. The method in
question "getTopStackFrame()" is an API method from
org.eclipse.debug.core.model.IThread.

Thanks for taking this, John. I have submitted bug 317226. Unfortunately
I can't attach the test program to this bug since it's a customer
application.

- Andy
 
-----Original Message-----
From: John Cortell <rat042@xxxxxxxxxxxxx>
Reply-to: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>, CDT General
developers list. <cdt-dev@xxxxxxxxxxx>
Subject: RE: [cdt-dev] Disassembly view throws NPE when debugging with
CDI
Date: Thu, 17 Jun 2010 12:21:23 -0500

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

John

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


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top