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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
