Loading ...
Sorry, an error occurred while loading the content.

31358Re: runaway vim processes

Expand Messages
  • Daniel Elstner
    Mar 3, 2003
    • 0 Attachment
      On Mon, 2003-03-03 at 21:05, Bram Moolenaar wrote:
      > Daniel Elstner wrote:
      > > 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.

      Yes, it's not pretty. My idea was that reducing the problem to SIGSEGV
      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 catch
      > out-of-stack errors. We _need_ the alternate stack, and it can't be
      > used when threading is enabled...

      There is a solution -- rebuild glibc with minimum kernel >= 2.4 :/

    • Show all 14 messages in this topic