RE: [cdt-dev] Change in behaviour in CDT3.0.2? Bug?

["dmsubs" <dmsubs@xxxxxxxxxxxxx>]

Done, as bug 136824

Thanks

---
Derek  

> -----Original Message-----
> From: Mikhail Khodjaiants [mailto:mikhailk@xxxxxxx] 
> Sent: 14 April 2006 08:11
> To: dmsubs@xxxxxxxxxxxxx; CDT General developers list.
> Subject: Re: [cdt-dev] Change in behaviour in CDT3.0.2? Bug?
> 
> The signal problem is a bug. Please, file a bugzilla entry 
> and attach the gdb output for "info signals".
> The console messages for "return" and "exit" come from gdb. 
> If you try to debug it using the command line gdb you will 
> get the same messages.
> Thanks.
> ----- Original Message -----
> From: "Derek Morris" <dmsubs@xxxxxxxxxxxxx>
> To: <cdt-dev@xxxxxxxxxxx>
> Sent: Thursday, April 13, 2006 2:25 PM
> Subject: [cdt-dev] Change in behaviour in CDT3.0.2? Bug?
> 
> 
> > Hi,
> >
> > I'm using CDT through gdb to debug a program running on a simulator.
> > When
> > the debugged program exits, the simulator is returning 
> GDB_SIGNAL0. In
> > CDT3.0.2 this is causing an exception - see the debug output below.
> > However,
> > it worked OK in 3.0.1 and 3.0.0.
> >
> > Also, I get slightly different behaviour in Eclipse depending on 
> > whether the program terminates by "return(0)" or "exit(0)". 
> With exit, 
> > control never returns to Eclipse, but I get the debug output below. 
> > With return, I get the same debug output, but I also get a 
> "Previous 
> > frame identical to this frame (corrupt stack?)" message 
> appearing in 
> > the debugger console window.
> >
> > When running GDB from the command line, I just get the following 
> > message Program received signal 0, Signal 0.
> > _exit (n=1) at <path to exit.c>12
> >
> > Is this a bug or a feature of CDT?
> >
> > *** Debug output ***
> >
> > [1,144,950,172,867] 171 info signal 0
> > [1,144,950,172,877] &"info signal 0\n"
> > [1,144,950,172,877] ~"Signal        Stop\tPrint\tPass to
> > program\tDescription\n"
> >
> > [1,144,950,172,877] &"Only signals 1-15 are valid as 
> numeric signals.\n"
> > [1,144,950,172,877] &"Use \"info signals\" for a list of symbolic 
> > signals.\n"
> > [1,144,950,172,887] 171^done
> > [1,144,950,172,887] (gdb)
> > java.lang.NullPointerException
> >        at
> > 
> org.eclipse.cdt.debug.mi.core.cdi.model.Signal.getName(Signal.java:49)
> >        at
> > 
> org.eclipse.cdt.debug.mi.core.cdi.SignalManager.findSignal(SignalManag
> > er
> > .jav
> > a:121)
> >        at
> > 
> org.eclipse.cdt.debug.mi.core.cdi.SignalManager.getSignal(Sign
> alManager.
> > java
> > :136)
> >        at
> > 
> org.eclipse.cdt.debug.mi.core.cdi.SignalManager.getSignal(Sign
> alManager.
> > java
> > :133)
> >        at
> > 
> org.eclipse.cdt.debug.mi.core.cdi.SignalReceived.<init>(SignalReceived
> > .j
> > ava:
> > 26)
> >        at
> > 
> org.eclipse.cdt.debug.mi.core.cdi.event.SuspendedEvent.getReason(Suspe
> > nd
> > edEv
> > ent.java:60)
> >        at
> > 
> org.eclipse.cdt.debug.internal.core.model.CDebugTarget.suspendThreads(
> > CD
> > ebug
> > Target.java:568)
> >        at
> > 
> org.eclipse.cdt.debug.internal.core.model.CDebugTarget.handleSuspended
> > Ev
> > ent(
> > CDebugTarget.java:1003)
> >        at
> > 
> org.eclipse.cdt.debug.internal.core.model.CDebugTarget.handleDebugEven
> > ts
> > (CDe
> > bugTarget.java:804)
> >        at
> > 
> org.eclipse.cdt.debug.mi.core.cdi.EventManager.fireEvents(EventManager
> > .j
> > ava:
> > 249)
> >        at
> > 
> org.eclipse.cdt.debug.mi.core.cdi.EventManager.update(EventMan
> ager.java:
> > 217)
> >        at java.util.Observable.notifyObservers(Unknown Source)
> >        at
> > 
> org.eclipse.cdt.debug.mi.core.MISession.notifyObservers(MISession.java
> > :6
> > 21)
> >        at
> > org.eclipse.cdt.debug.mi.core.EventThread.run(EventThread.java:46)
> >
> > ---
> > Derek
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
>