Debugging threads

[Uwe Bonnes]

Hello,

how to  debug a programm with a hanging thread?
When interrupting the debugger with ^C, gdb always land in the idle thread.

How do other people handle that problem?

Probably something like
https://github.com/gsmcmullin/gdb_chibios
implemented for NutOs would be usefull. Any volunteers?

Thanks

--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] ------- Fax. [phone] ---------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ole Reinhardt-2]

Hi Uwe,

I remember we had a similar discussion quite some time ago. If I
remember correctly, someone just wrote Nut/OS for gdb some (long) time
ago. But I'm very unsure...

I think you'd need a tracing solution. If the debugger stops in the idle
thread you'll quite likely be in the idle thread, which means that your
code waits for something (for some data on a socket or uart, a mutex, a
sleep, etc.) an no other thread is runnable.

So you ideally need to trace back your code path into the past to see
from where you changed into the idle thread.


Best regards,

Ole

Am 28.06.2018 um 15:28 schrieb Uwe Bonnes:

> Hello,
>
> how to  debug a programm with a hanging thread?
> When interrupting the debugger with ^C, gdb always land in the idle thread.
>
> How do other people handle that problem?
>
> Probably something like
> https://github.com/gsmcmullin/gdb_chibios
> implemented for NutOs would be usefull. Any volunteers?
>
> Thanks
>

--
Embedded-IT
Alter Weg 3
57223 Kreuztal
http://www.embedded-it.de

Tel.: [phone]
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Uwe Bonnes]

>>>>> "Ole" == Ole Reinhardt <[hidden email]> writes:

    Ole> Hi Uwe, I remember we had a similar discussion quite some time
    Ole> ago. If I remember correctly, someone just wrote Nut/OS for gdb
    Ole> some (long) time ago. But I'm very unsure...

    Ole> I think you'd need a tracing solution. If the debugger stops in the
    Ole> idle thread you'll quite likely be in the idle thread, which means
    Ole> that your code waits for something (for some data on a socket or
    Ole> uart, a mutex, a sleep, etc.) an no other thread is runnable.

    Ole> So you ideally need to trace back your code path into the past to
    Ole> see from where you changed into the idle thread.

Hello Ole,

nice to hear from you again!

In the meantime, I revived and fixed some issues in
 http://openocd.zylin.com/#/c/3881/

It works soemhow with on a nucle_l053 and I can see the threads. However
the hand does not happen on L053. On f3 discovery, where th thread hang
happens, OpenOcd has the old problems with halting the target and the thread
list does not make sense. I have to dig deeper.

And maybe I have to activate and understand SWO...

Bye
--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] ------- Fax. [phone] ---------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion