On Wed, 2010-06-02 at 10:36 +0200, Gilles Chanteperdrix wrote:
> 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.
>
Actually, we could extend this logic and forge a stack frame to return
to the preempted application code via some userland trampoline code,
doing the switch:
[watchdog trigger]
forge_return_frame(on =regs->sp, to =regs->pc);
regs->pc = __oops_I_did_it_again;
__oops_I_did_it_again:
__xn_migrate(LINUX_DOMAIN);
ret (via forged frame)
The thing is, that this brings in some arch-dep code to forge a stack
frame (like the kernel uses for signals), that should rather live in the
pipeline core.
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
