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

Re: runaway vim processes

Expand Messages
  • Daniel Elstner
    Hi, thanks a lot for the feedback. It turned out to be indeed helpful, see below. ... (It s probably not the issue but nonetheless a good idea to rm
    Message 1 of 16 , Mar 3 1:02 AM
    • 0 Attachment
      Hi,

      thanks a lot for the feedback. It turned out to be indeed helpful, see
      below.

      On Mon, 2003-03-03 at 09:55, Sean Richards wrote:
      > Daniel Elstner wrote:
      > > Darn. Oh well. Could you please mail me the ./configure arguments you
      > > used, the output of ./configure, the arguments used for compiling and
      > > linking (:version tells you), plus the output of 'ldd src/vim'? Hmm
      > > that's a lot, but nonetheless it'd be really helpful :)
      >
      > As requested
      >
      > [1] ./configure arguments
      >
      > #!/bin/sh
      >
      > ./configure --enable-gui=gtk --with-features=huge --with-compiledby=sean@darkstar --enable-pythoninterp --enable-rubyinterp --enable-cscope
      >
      > [2] output from configure
      >
      > loading cache auto/config.cache

      (It's probably not the issue but nonetheless a good idea to
      rm src/auto/config.cache before reconfiguring. Just in case.)

      [...]

      > [3] output from :version
      >
      > :version
      > VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 3 2003 21:28:11)
      > Included patches: 1-290

      [...]

      > Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-1.2
      > -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -I/usr/X
      > 11R6/include -I/usr/include/python2.2 -pthread -I/usr/local/lib/ruby/1.6/i686-linux

      That's fine, -pthread is there.

      > Linking: gcc -L/usr/X11R6/lib -rdynamic -L/usr/local/lib -o vim -L/usr/lib -L/usr/
      > X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lXt -lncurses -lgpm -ld
      > l -L/usr/lib/python2.2/config -lpython2.2 -ldl -lpthread -lutil -Xlinker -export-dyna
      > mic /usr/local/lib/ruby/1.6/i686-linux/libruby.a -ldl -lcrypt -lm

      There's the bugger: -lpthread should not be there. Do

      rm src/vim
      rm src/src/auto/link.sed

      and try again. link.sh should print messages like "Trying to remove the
      pthread library..." and either "we don't need the pthread library!" or
      "we DO need the pthread library". Hopefully the first.

      With some luck you just had a stale link.sed in the tree, otherwise this
      will need further investigation. Please mail me your results in either
      case :)

      Thanks,
      --Daniel
    • Sean Richards
      ... I had already done a make clean so that should have been taken care of. ... I am sad to report that the output from link.sh includes the lines ...
      Message 2 of 16 , Mar 3 1:35 AM
      • 0 Attachment
        Daniel Elstner wrote:
        > Hi,
        >
        > thanks a lot for the feedback. It turned out to be indeed helpful, see
        > below.

        > > [3] output from :version
        > >
        > > :version
        > > VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 3 2003 21:28:11)
        > > Included patches: 1-290
        >
        > [...]
        >
        > > Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-1.2
        > > -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -I/usr/X
        > > 11R6/include -I/usr/include/python2.2 -pthread -I/usr/local/lib/ruby/1.6/i686-linux
        >
        > That's fine, -pthread is there.
        >
        > > Linking: gcc -L/usr/X11R6/lib -rdynamic -L/usr/local/lib -o vim -L/usr/lib -L/usr/
        > > X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lXt -lncurses -lgpm -ld
        > > l -L/usr/lib/python2.2/config -lpython2.2 -ldl -lpthread -lutil -Xlinker -export-dyna
        > > mic /usr/local/lib/ruby/1.6/i686-linux/libruby.a -ldl -lcrypt -lm
        >
        > There's the bugger: -lpthread should not be there. Do
        >
        > rm src/vim
        > rm src/src/auto/link.sed

        I had already done a 'make clean' so that should have been taken care
        of.

        > and try again. link.sh should print messages like "Trying to remove the
        > pthread library..." and either "we don't need the pthread library!" or
        > "we DO need the pthread library". Hopefully the first.

        I am sad to report that the output from link.sh includes the lines ...

        link.sh: Trying to remove the pthread library...
        link.sh: We DO need the pthread library.

        > With some luck you just had a stale link.sed in the tree, otherwise this
        > will need further investigation. Please mail me your results in either
        > case :)

        Cheers, Sean :)

        --
        +---------------------------------------------------------------+
        | All spelling errors are intentional and are there to show new |
        | and improved ways of spelling old words. |
        +---------------------------------------------------------------+
      • Daniel Elstner
        Hey, I found some interesting information on the issue. This Debian bug report explains what s going on:
        Message 3 of 16 , Mar 3 8:01 AM
        • 0 Attachment
          Hey,

          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.

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