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

Re: runaway vim processes

Expand Messages
  • Daniel Elstner
    ... 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
    Message 1 of 14 , Mar 3, 2003
    • 0 Attachment
      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?

      --Daniel
    • 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 2 of 14 , Mar 4, 2003
      • 0 Attachment
        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 3 of 14 , Mar 4, 2003
        • 0 Attachment
          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.