Jan Kiszka wrote:
> Tschaeche IT-Services wrote:
>> On Tue, Jun 01, 2010 at 04:32:37PM +0200, Philippe Gerum wrote:
>>> Not in the absence of syscall. We thought about this once already, when
>>> considering how a watchdog preempting a runaway task in primary mode
>>> could force a secondary mode switch: there is no sane and easy solution
>>> to this unfortunately.
>> This is exactly Sigmatek's problem: Our customers develop code
>> within our debugging/development environment. We want to catch
>> this situation (the developer implements a while(1)) with a
>> watchdog throwing SIGTRAP so that our debugger gets active
>> and can locate the problem according to the stack frame...
>
> CONFIG_XENO_OPT_WATCHDOG is probably what you are looking for. It tries
> to catch "well-behaving" broken threads via SIGDEBUG and kills the
> hopelessly broken rest - system alive again.
>
> You can then debug the former and need to do code review on the latter.
> Or you could also try to add some loop-breaking Xenomai syscalls (or
> even more clever checks) to library services the code under suspect
> usually invokes.
I am afraid "well-behaving" means emitting syscalls. We have a radical
way to cause a SIGSEGV to be sent to a thread having run amok: set its
PC to an invalid address (after having printed the real PC). gdb will
not be able to print where the program stopped, but should be able to
print the backtrace.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
