> In the course of the investigation, I found another spot, where we
> didn't get a core dump, which started this whole thread. Guess what,
> people aren't happy either. One workaround would be to never use the
> signal stack, but if this can be fixed properly, I would see more
> happy faces at work. And I like happy faces.
Well, the most reliable way to get a core dump when you trash the
stack or something is to have no SIGSEGV handler at all. :)
In any case, there are all sorts of things that could go wrong and
leave the process stuck in an infinite loop. If you really want a
core dump when things go wrong then you probably need some sort of
watchdog process plus a way for one process to force another to dump
core and exit (like a SIGKILL but with a core dump as well).
> There is an open source web server that, combined with a closed source
> library, fscks up your stack pointer. I don't know how they did it
On PPC? Sounds like you are overrunning an array on the stack and
clearing the stack backchain word.
> and I don't even care. What I do care about is that it happened, that
> it can happen again any time, and that we handle this problem as
> gracefully as possible. A core dump is graceful, a do_exit(SIGSEGV),
> as it was in the ppc code is not, and an inifite loop is anything but
> graceful.
>
> I agree that my initial patch can cause other problems, but the
> problem itself should still get fixed.
You haven't convinced me that the kernel is doing anything wrong or
even suboptimal - it seems to me that you have run into some
unintended consequences of your code, that's all. You can't expect
the kernel to work around all the bugs in your user processes. :)
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/