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

Re: runaway vim processes

Expand Messages
  • Bram Moolenaar
    ... That s what you get when double checking for errors... I think the simplest way is to undefine HAVE_GETRLIMIT in auto/config.h and compile again. Since we
    Message 1 of 14 , Mar 4, 2003
      Daniel Elstner wrote:

      > On Die, 2003-03-04 at 08:55, Daniel Elstner wrote:
      > > On Mon, 2003-03-03 at 21:05, Bram Moolenaar wrote:
      > >
      > > > The solution would not work though: Catching SIGSEGV on the alternate
      > > > stack works (assuming that longjmp() works with threading).
      > >
      > > I just confirmed that at least that part still works. Inserting a
      > > recursive call early in regmatch() successfully resulted in E363, and
      > > Vim did not crash.
      >
      > Ooops, sorry, I take that back. /me just realized that there is an
      > explicit call to mch_stackcheck() in regmatch(). Is there any simple
      > way to test the functionality of the signal handler?

      That's what you get when double checking for errors...

      I think the simplest way is to undefine HAVE_GETRLIMIT in auto/config.h
      and compile again.

      Since we do HAVE_GETRLIMIT on linux, and threading may cause a hang, it
      might be better to rely on mch_stackcheck() and not use the alternate
      stack. Thus use your #ifdef around setting sa.sa_flags, also for
      SIGSEGV.

      /* Setup to use the alternate stack for the signal function. */
      sa.sa_handler = func_deadly;
      sigemptyset(&sa.sa_mask);
      # if defined(__linux__) && defined(_REENTRANT)
      /* Linux with kernel 2.2 has a bug in thread handling in
      * combination with using the alternate stack: library functions
      * will use the ordinary stack anyway, causing a SEGV signal,
      * which recursively calls deathtrap and hangs. */
      sa.sa_flags = 0;
      # else
      sa.sa_flags = SA_ONSTACK;
      # endif
      sigaction(signal_info[i].sig, &sa, NULL);

      Does that look OK?

      --
      SUPERIMPOSE "England AD 787". After a few more seconds we hear hoofbeats in
      the distance. They come slowly closer. Then out of the mist comes KING
      ARTHUR followed by a SERVANT who is banging two half coconuts together.
      "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
      \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
    • Daniel Elstner
      ... Yes, that sounds good to me. ... Yep. But I d change the wording of the comment to: /* On Linux, glibc compiled for minimum kernel 2.2 has a bug in *
      Message 2 of 14 , Mar 4, 2003
        On Die, 2003-03-04 at 10:25, Bram Moolenaar wrote:

        > Since we do HAVE_GETRLIMIT on linux, and threading may cause a hang, it
        > might be better to rely on mch_stackcheck() and not use the alternate
        > stack. Thus use your #ifdef around setting sa.sa_flags, also for
        > SIGSEGV.

        Yes, that sounds good to me.

        > /* Setup to use the alternate stack for the signal function. */
        > sa.sa_handler = func_deadly;
        > sigemptyset(&sa.sa_mask);
        > # if defined(__linux__) && defined(_REENTRANT)
        > /* Linux with kernel 2.2 has a bug in thread handling in
        > * combination with using the alternate stack: library functions
        > * will use the ordinary stack anyway, causing a SEGV signal,
        > * which recursively calls deathtrap and hangs. */
        > sa.sa_flags = 0;
        > # else
        > sa.sa_flags = SA_ONSTACK;
        > # endif
        > sigaction(signal_info[i].sig, &sa, NULL);
        >
        > Does that look OK?

        Yep. But I'd change the wording of the comment to:

        /* On Linux, glibc compiled for minimum kernel 2.2 has a bug in
        * thread handling in combination with using the alternate stack:
        * pthread library functions try to use the stack pointer to
        * identify the current thread, causing a SEGV signal, which
        * recursively calls deathtrap and hangs. */

        Otherwise people might get confused since Linux 2.2 is quite rare on
        desktop systems these days.

        --Daniel
      Your message has been successfully submitted and would be delivered to recipients shortly.