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

Re: runaway vim processes

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

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