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

Vim eats 100% CPU on loss of tty

Expand Messages
  • Aron Griffis
    Hi, Here are the steps to observe this bug: (1) ssh to localhost (2) run vim (3) kill sshd providing terminal to vim (4) run top to observe vim spinning
    Message 1 of 9 , Feb 1, 2002
      Hi,

      Here are the steps to observe this bug:

      (1) ssh to localhost
      (2) run vim
      (3) kill sshd providing terminal to vim
      (4) run top to observe vim spinning

      Connecting to the spinning vim process with "ltrace -p" provides the
      following:

      sigemptyset(0x08394300, 0, 0, 0, 7) = 0
      sigaction(1, 0x083942fc, 0, 0x0810adaf, 0x08394300 <unfinished ...>
      --- SIGSEGV (Segmentation fault) ---
      getrlimit64(3, 0x08393d08, 0x08393d18, 0x08107fa4, 0x40379a18) = 0
      sigemptyset(0x08393c40, 0x80000001, 0, 0x08393c24, 7) = 0
      sigaction(1, 0x08393c3c, 0, 0x0810adaf, 0x08393c40 <unfinished ...>
      --- SIGSEGV (Segmentation fault) ---
      getrlimit64(3, 0x08393648, 0x08393658, 0x08107fa4, 0x40379a18) = 0
      sigemptyset(0x08393580, 0x80000001, 0, 0x08393564, 7) = 0
      sigaction(1, 0x0839357c, 0, 0x0810adaf, 0x08393580 <unfinished ...>
      --- SIGSEGV (Segmentation fault) ---
      getrlimit64(3, 0x08392f88, 0x08392f98, 0x08107fa4, 0x40379a18) = 0
      sigemptyset(0x08392ec0, 0x80000001, 0, 0x08392ea4, 7) = 0
      sigaction(1, 0x08392ebc, 0, 0x0810adaf, 0x08392ec0 <unfinished ...>
      --- SIGSEGV (Segmentation fault) ---
      :
      :
      --- SIGSEGV (Segmentation fault) ---
      getrlimit64(3, 0x08393d08, 0x08393d18, 0x08107fa4, 0x40379a18) = 0
      sigemptyset(0x08393c40, 0x80000001, 0, 0x08393c24, 7) = 0
      sigaction(1, 0x08393c3c, 0, 0x0810adaf, 0x08393c40 <unfinished ...>
      --- SIGSEGV (Segmentation fault) ---
      getrlimit64(3, 0x08393648, 0x08393658, 0x08107fa4, 0x40379a18Error: call nesting too deep!
      Error: call nesting too deep!
      ) = 0
      sigemptyset(0x08393580, 0x80000001, 0, 0x08393564, 7) = 0
      sigaction(1, 0x0839357c, 0, 0x0810adaf, 0x08393580 <unfinished ...>
      --- SIGSEGV (Segmentation fault) ---

      The output continues until I ctrl-c, at which point vim quits. This is
      using vim-6.0.118 on Gentoo Linux.

      Thanks,
      Aron

      --
      Aron Griffis
      Tru64 UNIX LAN Drivers
      Compaq Computer Corporation, ZKO3-3/T30
    • Lubomir Host
      ... This bug was already reported. I m using vim-6.0.158 and has same bug. Have I good undesrstood description for patch 6.0.145 ? -- Lubomir Host Platon
      Message 2 of 9 , Feb 1, 2002
        On Fri, Feb 01, 2002 at 05:56:17PM -0500, Aron Griffis wrote:
        > Hi,
        >
        > Here are the steps to observe this bug:
        >
        > (1) ssh to localhost
        > (2) run vim
        > (3) kill sshd providing terminal to vim
        > (4) run top to observe vim spinning
        >
        > Connecting to the spinning vim process with "ltrace -p" provides the
        > following:
        > ...
        > The output continues until I ctrl-c, at which point vim quits. This is
        > using vim-6.0.118 on Gentoo Linux.

        This bug was already reported. I'm using vim-6.0.158 and has same
        bug. Have I good undesrstood description for patch 6.0.145 ?

        --
        Lubomir Host
        Platon software development group
      • dman
        ... Yes. ... I don t know, what is your understanding ;-)? The description of that patch doesn t affect the above mentioned bug. The problem is theh
        Message 3 of 9 , Feb 1, 2002
          On Sat, Feb 02, 2002 at 04:05:37AM +0100, Lubomir Host wrote:
          | On Fri, Feb 01, 2002 at 05:56:17PM -0500, Aron Griffis wrote:
          | > Hi,
          | >
          | > Here are the steps to observe this bug:
          | >
          | > (1) ssh to localhost
          | > (2) run vim
          | > (3) kill sshd providing terminal to vim
          | > (4) run top to observe vim spinning
          | >
          | > Connecting to the spinning vim process with "ltrace -p" provides the
          | > following:
          | > ...
          | > The output continues until I ctrl-c, at which point vim quits. This is
          | > using vim-6.0.118 on Gentoo Linux.
          |
          | This bug was already reported.

          Yes.

          | I'm using vim-6.0.158 and has same bug. Have I good undesrstood
          | description for patch 6.0.145 ?

          I don't know, what is your understanding ;-)?

          The description of that patch doesn't affect the above mentioned bug.
          The problem is theh combination of threads and signals. Someone
          reported that an authoritative book on POSIX threads advises against
          using threads and signals in the same program. The bug is that vim
          gets errors reading from stdin and gets into an infinite recursion
          with threads and a signal. Sending SIGKILL stops it. I don't know of
          any easy fix. (BTW, since threads are involved this is also system
          specific. Bram reported no success in recreating the problem on his
          FreeBSD box)

          -D

          --

          A man of many companions may come to ruin,
          but there is a friend that sticks closer than a brother.
          Proverbs 18:24
        • Bram Moolenaar
          ... [...] I m not convinced this is a problem in Vim itself. It s possibly a problem in a library function. Did you try compiling without python? --
          Message 4 of 9 , Feb 2, 2002
            Aron Griffis wrote:

            > Here are the steps to observe this bug:
            >
            > (1) ssh to localhost
            > (2) run vim
            > (3) kill sshd providing terminal to vim
            > (4) run top to observe vim spinning
            >
            > Connecting to the spinning vim process with "ltrace -p" provides the
            > following:
            >
            > sigemptyset(0x08394300, 0, 0, 0, 7) = 0
            > sigaction(1, 0x083942fc, 0, 0x0810adaf, 0x08394300 <unfinished ...>
            > --- SIGSEGV (Segmentation fault) ---
            > getrlimit64(3, 0x08393d08, 0x08393d18, 0x08107fa4, 0x40379a18) = 0
            > sigemptyset(0x08393c40, 0x80000001, 0, 0x08393c24, 7) = 0
            > sigaction(1, 0x08393c3c, 0, 0x0810adaf, 0x08393c40 <unfinished ...>

            [...]

            I'm not convinced this is a problem in Vim itself. It's possibly a
            problem in a library function. Did you try compiling without python?

            --
            hundred-and-one symptoms of being an internet addict:
            154. You fondle your mouse.

            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
            ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
          • Aron Griffis
            Hello Bram, Bram Moolenaar wrote: [Sat Feb 2 2002, 6:03:25AM EST] ... Good call, it seems to work fine when the Python interpreter isn t included. However
            Message 5 of 9 , Feb 2, 2002
              Hello Bram,

              Bram Moolenaar wrote: [Sat Feb 2 2002, 6:03:25AM EST]
              > I'm not convinced this is a problem in Vim itself. It's possibly a
              > problem in a library function. Did you try compiling without python?

              Good call, it seems to work fine when the Python interpreter isn't
              included. However Gentoo Linux developers generally prefer Python over
              other interpreters, so it seems a shame to leave it out. Do you know
              how it should be fixed, or at least band-aid the problem?

              IMHO, these kinds of bugs are pretty important to fix (even if
              ultimately the problem lies in Python). Vim is made much more powerful
              by the ability to script it in multiple languages.

              There is also a bug in the tcl interpreter that I've noticed, so I leave
              it out of the Gentoo build. When I use --enable-tclinterp, then the
              following command never returns:

              VIMINIT='let OS = system("uname -s")' vim

              Thanks,
              Aron

              --
              Aron Griffis
              Tru64 UNIX LAN Drivers
              Compaq Computer Corporation, ZKO3-3/T30
            • Bram Moolenaar
              ... I can t reproduce the problem (on FreeBSD), so at least it depends on the system. It has something to do with threads and signals. Using the python
              Message 6 of 9 , Feb 2, 2002
                Aron Griffis wrote:

                > Bram Moolenaar wrote: [Sat Feb 2 2002, 6:03:25AM EST]
                > > I'm not convinced this is a problem in Vim itself. It's possibly a
                > > problem in a library function. Did you try compiling without python?
                >
                > Good call, it seems to work fine when the Python interpreter isn't
                > included. However Gentoo Linux developers generally prefer Python over
                > other interpreters, so it seems a shame to leave it out. Do you know
                > how it should be fixed, or at least band-aid the problem?

                I can't reproduce the problem (on FreeBSD), so at least it depends on
                the system. It has something to do with threads and signals. Using the
                python interface introduces threads.

                > IMHO, these kinds of bugs are pretty important to fix (even if
                > ultimately the problem lies in Python). Vim is made much more powerful
                > by the ability to script it in multiple languages.

                It might not be so easy to fix this bug. Perhaps there is a version of
                Python without threads? Or a thread-safe version of the libraries? On
                my system I must compile with "-pthread" to avoid problems.

                > There is also a bug in the tcl interpreter that I've noticed, so I leave
                > it out of the Gentoo build. When I use --enable-tclinterp, then the
                > following command never returns:
                >
                > VIMINIT='let OS = system("uname -s")' vim

                Works fine for me (on FreeBSD again).

                --
                hundred-and-one symptoms of being an internet addict:
                161. You get up before the sun rises to check your e-mail, and you
                find yourself in the very same chair long after the sun has set.

                /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
              • Aron Griffis
                Bram Moolenaar wrote: [Sat Feb 2 2002, 1:37:18PM EST] ... I ll investigate these questions. Gcc doesn t have a -pthread option. I know that leaving threads
                Message 7 of 9 , Feb 2, 2002
                  Bram Moolenaar wrote: [Sat Feb 2 2002, 1:37:18PM EST]
                  > It might not be so easy to fix this bug. Perhaps there is a version of
                  > Python without threads? Or a thread-safe version of the libraries? On
                  > my system I must compile with "-pthread" to avoid problems.

                  I'll investigate these questions. Gcc doesn't have a -pthread option.
                  I know that leaving threads out would be unfortunate for my friend who
                  writes Python-based threaded Vim plugins. :-)

                  Does the Perl interpreter not have this problem, even when threads are
                  enabled? If not, I wonder what the difference is.

                  > > There is also a bug in the tcl interpreter that I've noticed, so I leave
                  > > it out of the Gentoo build. When I use --enable-tclinterp, then the
                  > > following command never returns:
                  > >
                  > > VIMINIT='let OS = system("uname -s")' vim
                  >
                  > Works fine for me (on FreeBSD again).

                  I spent a while trying to debug this on Linux and didn't get that far.
                  But I didn't care much about the tcl interpreter, so finally I just left
                  it out of the Gentoo ebuild.

                  Thanks,
                  Aron

                  --
                  Aron Griffis
                  Tru64 UNIX LAN Drivers
                  Compaq Computer Corporation, ZKO3-3/T30
                • Matthew Hawkins
                  ... It does on FreeBSD, where it signals that ld should link with the reentrant version of libc instead of the non-reentrant version. This is because the
                  Message 8 of 9 , Feb 2, 2002
                    On Sat, 02 Feb 2002, Aron Griffis wrote:
                    > I'll investigate these questions. Gcc doesn't have a -pthread option.

                    It does on FreeBSD, where it signals that ld should link with the
                    reentrant version of libc instead of the non-reentrant version.
                    This is because the pthread library functions are in the reentrant
                    version of libc and not a separate pthread library. It also supposedly
                    alters a few other library functions so they are thread safe.

                    I've seen the problem here on a Linux box twice in the past month or
                    so, it's also an SMP system so I don't know if that matters or not.
                    I never ssh into my freebsd box so I've never noticed it on that
                    platform. I haven't seen it happen on Solaris either, though that's
                    through lack of trying ;)

                    --
                    Matt
                  • Denis Perelyubskiy
                    ... [...] actually, my vim is -python , and i recently saw the same thing.... sorry, did not attach to the process. will do the next time it happens... denis
                    Message 9 of 9 , Feb 10, 2002
                      * Aron Griffis <agriffis@...> [02-Feb-02 10:15 -0800]:
                      >
                      >Hello Bram,
                      >
                      >Bram Moolenaar wrote: [Sat Feb 2 2002, 6:03:25AM EST]
                      >> I'm not convinced this is a problem in Vim itself. It's possibly a
                      >> problem in a library function. Did you try compiling without python?
                      >
                      >Good call, it seems to work fine when the Python interpreter isn't
                      >included. However Gentoo Linux developers generally prefer Python over
                      >other interpreters, so it seems a shame to leave it out. Do you know
                      >how it should be fixed, or at least band-aid the problem?
                      [...]

                      actually, my vim is '-python', and i recently saw the same
                      thing.... sorry, did not attach to the process. will do the
                      next time it happens...

                      denis

                      --
                      // mailto: Denis Perelyubskiy <denisp@...>
                      // icq : 12359698
                      // PGP : http://www.cs.ucla.edu/~denisp/files/pgp.asc
                    Your message has been successfully submitted and would be delivered to recipients shortly.