Re: [Xenomai-help] Debugging in Xenomai

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

Peter Soetens wrote:
> On Thursday 23 November 2006 16:25, Daniel Schnell wrote:
>> One of the next steps would be finding out which actual function back
>> trace the suspicious thread has. So I execute gdb and try to attach to
>> the appropriate process, which works. Problem: sending Ctrl-C doesn't
>> work, independant of if gdb is executed via ssh or serial console. So I
>> cannot stop the actual program beeing debugged, rendering the gdb
>> approach useless. Also sending SIGINT to the GDB process doesn't work.
>> It seems to be simply ignored. As I understand CTRL-C is effectively
>> sending SIGINT and is sent to GDB itself and not to the underlying appl.
> 
> We had a similar issue while debugging an RTNET app (main thread + 1 xenomai 
> posix skin thread) under xenomai. I don't recall exactly the circumstances, 
> but the app was blocked on a socket, and a Ctrl-C did not work. A 'killall 
> gdb' (SIGTERM) did come through and killed gdb. If you (the Xeno/RTNet 
> developers)'re interested in this case, I'll see if I can get more info.

You're welcome.

I just checked the behaviour of examples/xenomai/posix/eth_p_all over
gdb. I can interrupt the blocking recv - so far so good - but the
syscall is unfortunately not replayed when continuing. Instead, the
program just terminates because some error (EINTR) is reported to the
application.

[Too lazy to dig:] Philippe, isn't syscall restarting after an
interruption the job of the Xenomai nucleus?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]