Jan Kiszka wrote: > Philippe Gerum wrote: >> On Fri, 2006-11-24 at 11:41 +0100, Jan Kiszka wrote: >>> 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? >> Yes, it is, and normally, it does so. >> >> syscall(): >> return -EINTR >> do_hi/lo_syscall_event(): >> request_syscall_restart(): >> if (syscall_return == -EINTR) pass back -ERESTARTSYS >> Linux ret_from_syscall: >> do_notify_resume upon sig, which eventually checks for >> -ERESTARTSYS then fixes $pc to restart the interrupted call. >> This is regular Linux code, Xenomai relies on it, but does not >> change it. >> >> Issue #1: a blocking Xenomai syscall does not detect the XNBREAK >> condition properly upon return from xnpod_suspend_thread() or >> xnsynch_sleep_on(), therefore does not pass back -EINTR to the nucleus >> when this bit is raised for the current thread, which causes the signal >> to be left over. Usually, the consequence of this is "please find the >> reset button, and exercise your firmware once more". This said, weird >> behaviour instead of total freeze has been experienced in this context, >> too. >> >> Issue #2: user-space switches signal handling to SysV behaviour instead >> of the BSDish one, thus preventing syscall restart in favour of getting >> a failure return code with errno == -EINTR. Usually not the case, but, >> this deserves a verification. >> >> Issue #3: Oops. We have a bug. >> > > I take (a variant of) #1 - RTnet bug... >
Commit #1088 fixes RTnet so that signals to threads blocking on receive sockets (packet and udp) now correctly cause a restart of the syscall after the signal has been handled. I'm not sure that this is related to your gdb issue, Peter, but maybe you can re-check. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
