31358Re: runaway vim processes
- Mar 3, 2003On Mon, 2003-03-03 at 21:05, Bram Moolenaar wrote:
> Daniel Elstner wrote:Yes, it's not pretty. My idea was that reducing the problem to SIGSEGV
> > I found some interesting information on the issue. This Debian bug
> > report explains what's going on:
> > http://lists.debian.org/debian-glibc/2002/debian-glibc-200212/msg00347.html
> > As mentioned in the mail, the problem with coroutines also applies to
> > sigaltstack(). There seems to be only one way around the problem:
> > simply don't use sigaltstack().
> > The attached patch disables the alternative stack if compiling on Linux
> > with pthreads, except for SIGSEGV. This is AFAIK the only signal for
> > which the alternative stack is really necessary. Thus there shouldn't
> > be a regression in functionality when switching to fixed-up pthreads
> > some day.
> This makes sense. I'm glad you found out about this Linux problem.
> The solution would not work though: Catching SIGSEGV on the alternate
> stack works (assuming that longjmp() works with threading).
> But when SIGSEGV occurs for another reason it would run into the problem
> with the stack pointer and generate another SIGSEGV, thus loop forever.
is a lot better than the current situation, and switching to a fixed
pthread (i.e. glibc compiled with minimum kernel >= 2.4) would fix the
problem without recompiling Vim.
SIGSEGV is fatal in most apps; Vim will just behave slightly more
annoying and livelock instead of crashing immediately. And for this we
can blame someone else.
> I cannot think of a solution without losing the ability to catchThere is a solution -- rebuild glibc with minimum kernel >= 2.4 :/
> out-of-stack errors. We _need_ the alternate stack, and it can't be
> used when threading is enabled...
- << Previous post in topic Next post in topic >>