Re: [cdt-dev] Show Reason for Crash When Core Debugging

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

Hi Adam,

The short answer is yes, it is possible to create the event, or a new
subclass if appropriate.

If the output when you do the -target-select [...] has the (textual)
information you need, you should be able to obtain a suitable
IExecutionDMContext from the MIProcesses service that adequately
describes your thread.

Please send along some code snippets of what does not work if you are
having further issues and I am sure someone here can help.

Of course, I will echo Marc's feedback that I hope you contribute back
this improvement. Also, if GDB does not provide an MI command, it
would be best to (in addition) make a request/patch for GDB too.

Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 15 June 2016 at 20:21, Adam Ward <award@xxxxxxxxxxxxxx> wrote:
> The text could be added to the process level instead. I have exhausted the
> route of sending a command to GDB, there isn’t one that returns the reason
> for the crash. The signal that produced the core file is only outputted when
> the connection is setup with the core file using the “-target-select core
> <core file>” command. The only possible route looks to be parsing the signal
> and reason from the MIStreamConsoleOutput received in eventReceived. Is it
> possible to create and dispatch an MISignalEvent this way or create a new
> event for this?
>
>
>
> Adam
>
>
>
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Marc Khouzam
> Sent: Wednesday, June 15, 2016 1:01 PM
> To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> Subject: Re: [cdt-dev] Show Reason for Crash When Core Debugging
>
>
>
> You will need to figure out which thread caused the crash.
> I don't see that information given by GDB when quickly looking at some
> traces.
> There may be a command you can send to GDB that will provide that info,
> but I don't know myself.
>
> So, if you can figure out the thread id from the output received in
> eventReceived,
> you are set.  If you cannot, then you need some other way to find the
> crashed thread;
> if you find such a way, you will probably need a different mechanism to sent
> such a
> request to GDB, like an extra step in the FinalLaunchSequence for a core
> file case.
> If you cannot find a way to know which thread caused the crash, then, what
> you can
> do is add the crash text to the process level instead of the thread level.
>
> If you do find a way to know which thread crashed, come back to use and we
> can
> clarify a way forward based on your finding.
>
> Also, you can make the suggestion to the GDB community to properly report
> a crashed thread in this case.  It sounds like a missing feature if they
> don't
> do that already.
>
> Finally, I'd love to see this contributed back to CDT if you get it working.
>
> Thanks
>
> ________________________________
>
> From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of
> Adam Ward [award@xxxxxxxxxxxxxx]
> Sent: June 15, 2016 11:19 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] Show Reason for Crash When Core Debugging
>
> Hi all,
>
>
>
> I'm augmenting core debugging to show the reason for the crash on the thread
> label in the debug view (like what is seen when a process crashes while
> actively being debugged). I can see that when a process crashes while being
> debugged a MIExecAsyncOutput event is received by the eventReceived(Object)
> method in MIRunControlEventProcessor. The MIExecAsyncOutput event is used to
> create an MISignalEvent which is dispatched to update the UI. During core
> debugging an MITargetSelectCore command causes MIConsoleStreamOutput event
> to be received by this same eventReceived(Object) method which contains the
> signal and meaning in a string ("Program terminated with signal <signal>,
> <reason>"). Is there a way I can get an IExecutionDMContext from the
> MIConsoleStreamOutput so I can build an MISignalEvent or is there a better
> way of trying to accomplish this?
>
>
>
> Thanks,
>
> Adam
>
>
>
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cdt-dev