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

VimGDB and ifndef HAVE_SELECT

Expand Messages
  • Xavier de Gaye
    ... So HP-UX 11.0 does not have select() and must use poll(), this is interesting for what follows. Maybe you could send a bug report to , so
    Message 1 of 19 , Mar 24, 2004
    • 0 Attachment
      On Wed, 17 Mar 2004 Malte Neumann wrote:
      > Hi,
      >
      > I am trying to use the VimGDB interface. Reading the manual it looks exactly
      > like what I was looking for a long time...
      >
      > But while installing I found a few problems:
      >
      > First of all I am working on a workstation running HP-UX 11.0.
      > The installation process worked very well in the beginning, no problem with
      > the patching or the configuration. But the compilation stopped several times:
      >
      > 1. In the file if_xcmdsrv.c in line 595 (approx) the struct pollfd is used
      > but is not known. The problem could be fixed by including the following code
      > in the file (as is done also in gdb.c)
      >
      > # ifndef HAVE_SELECT
      > # ifdef HAVE_SYS_POLL_H
      > # include <sys/poll.h>
      > # else
      > # ifdef HAVE_POLL_H
      > # include <poll.h>
      > # endif
      > # endif
      > # endif
      >
      So HP-UX 11.0 does not have select() and must use poll(), this is
      interesting for what follows.
      Maybe you could send a bug report to <bugs@...>, so that the above
      fix in if_xcmdsrv.c is included in future Vim releases.


      >
      > 2. In the files os_unix.c (lines 340 and 383) and gui.c (lines 2573 and
      > 2648) the variable start_tv is used if HAVE_SYS_TIME_H is defined. But this
      > variable is only defined (line 323 or 2525 resp.) when HAVE_SYS_TIME_H
      > *and* HAVE_GETTIMEOFDAY are defined. On my systems this seems to be not the
      > case, so I used the #else statement without start_tv.
      >
      > After applying these corrections it compiled ok.
      >
      My mistake, thanks. I will change the above lines in VimGDB next patch
      and replace:

      # if defined(HAVE_SYS_TIME_H)
      with
      #if defined(HAVE_GETTIMEOFDAY) && defined(HAVE_SYS_TIME_H)


      >
      > Now I have still have another small problem:
      >
      > Starting gdb and sending commands to gdb works very well. I can load a file
      > set the arguments and run it. But when I try to set a breakpoint with e.g.
      >
      > :call gdb("break fluid3")
      >
      > gdb registers the breakpoint, but the corresponding file is not displayed.
      > The status line shows the correct file name and number of lines etc. but the
      > content of the file is not show and vim hangs and has to be killed. The same
      >
      Does this happen with vim on a plain terminal (rxvt) or with gvim,
      or with both ?

      What happens if you first edit the source file where fluid3() is
      defined and then set the breakpoint ?

      Also, if this occurs systematically and you don't mind compiling the
      whole Vim source code with -g, you could start a plain GDB process
      in another terminal once VimGDB is locked, and then run the GDB command
      "attach VimGDB_pid" and send me the backtrace. This would help a lot.
      To recompile Vim with -g, uncomment "#CFLAGS = -g" in the Makefile and
      then do "make reconfig".


      > content of the file is not show and vim hangs and has to be killed. The same
      > thing happens when opening a source file with :e.
      >
      Does the last sentence means that after setting the breakpoint, you
      cannot edit any file, or is it also after starting gdb ?


      >
      > Sometimes vim even crashes when sourcing the gdb_mappings.vim file.
      > Running the core file in gdb gives the following information:
      >
      > Program terminated with signal 11, Segmentation fault.
      > Unable to find __dld_flags symbol in object file.
      >
      Can you get a backtrace of this (same procedure as above, only you
      attach before the crash, before sourcing the gdb_mappings.vim file) ?

      I am running Linux here. To get Vim to run with poll() and not using
      gettimeofday() so as to get closer to your setup, I compiled Vim after
      commenting out in auto/config.h:

      //#define HAVE_GETTIMEOFDAY 1
      //#define HAVE_SELECT 1

      This version of VimGDB using poll() runs fine in plain terminal mode
      on Linux as far as I can tell.

      However it does run badly in GUI mode (gvim). It does not hang as you
      are reporting on HP-UX, but the first keystroke after any
      ":call gdb(...)" is ignored and only shows up after a second keystroke.

      The bug is in VimGDB handling of the last two nested loops in
      gui_wait_for_chars() in gui.c:

      the last before last loop (a) starts with:
      2642: while ((retval = gui_mch_wait_for_chars(wtime)) == FAIL)
      the last loop (b) is nested within the previous loop (a) and starts
      with:
      2680: for (;;)

      When gui_mch_wait_for_chars(-1L) returns with OK in the last nested
      loop (b), a break statement is missing and we should exit both loops
      instead of doing a new iteration in loop (a). Even worse, this new
      iteration in loop (a) may cause gui_mch_wait_for_chars() to be invoked
      with wtime == 0 !

      This does also occur when VimGDB is compiled with select() and
      gettimeofday() but is not so obvious to the user. The difference
      between both behaviour stems from the fact that with poll (and without
      gettimeofday), the computation of the estimation of the remaining wtime
      returned by gdb_process_output is gross and way too large (the
      second bug).

      Both these bugs above lead to the two following fixes and solve the
      problem on my Linux box here.


      *** gui.c.ORIG Wed Mar 24 11:42:45 2004
      --- gui.c Wed Mar 24 11:48:14 2004
      ***************
      *** 2639,2645 ****
      #ifdef FEAT_GDB
      {
      wtime = p_ut;
      ! while ((retval = gui_mch_wait_for_chars(wtime)) == FAIL)
      {
      if (gdb_event(gdb) && gdb_allowed(gdb))
      {
      --- 2639,2646 ----
      #ifdef FEAT_GDB
      {
      wtime = p_ut;
      ! retval = FAIL;
      ! while (wtime != 0 && (retval = gui_mch_wait_for_chars(wtime)) == FAIL)
      {
      if (gdb_event(gdb) && gdb_allowed(gdb))
      {
      ***************
      *** 2698,2703 ****
      --- 2699,2707 ----
      #ifdef FEAT_AUTOCMD
      once_already = 0;
      #endif
      + #ifdef FEAT_GDB
      + break;
      + #endif
      }
      }
      #ifdef FEAT_GDB



      *** gdb.c.ORIG Wed Mar 24 11:42:44 2004
      --- gdb.c Wed Mar 24 11:45:44 2004
      ***************
      *** 1376,1383 ****
      pstart->tv_sec = tv.tv_sec; /* reset start time */
      pstart->tv_usec = tv.tv_usec;
      # else
      ! /* guess: interrupted halfway, gdb processing 10 msecs */
      ! wtime = wtime / 2 - 10L;
      # endif
      }
      }
      --- 1376,1383 ----
      pstart->tv_sec = tv.tv_sec; /* reset start time */
      pstart->tv_usec = tv.tv_usec;
      # else
      ! /* gdb processing 10 msecs */
      ! wtime -= 10L;
      # endif
      }
      }


      I am afraid this will not solve the problem on HP-UX. For the
      case it does, it would be very helpful if you applied first the fix in
      gui.c, test it and then apply the fix in gdb.c and test it again.
      The reason for doing that is that the second fix in gdb.c might only
      hide the bug (if it does) and it's good to know.

      >
      > :version gives:
      >
      > VIM - Vi IMproved 6.2 (2003 Jun 1, compiled Mar 16 2004 18:37:01)
      > Compiled by neumann@stat38
      > Big version with GTK GUI. Features included (+) or not (-):
      > +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
      > +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist
      > +cmdline_info +comments +cryptv +cscope +dialog_con_gui +diff +digraphs
      > +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
      > +find_in_path +folding -footer +fork() +gdb -gettext -hangul_input +iconv
      > +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent
      > +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape
      > +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm
      > +multi_byte +multi_lang +netbeans_intg -osfiletype +path_extra -perl
      > +postscript +printer -python +quickfix +rightleft -ruby +scrollbind +signs
      > +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
      > +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects
      > +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra
      > +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11
      > +xfontset +xim -xsmp +xterm_clipboard -xterm_save
      > system vimrc file: "$VIM/vimrc"
      > user vimrc file: "$HOME/.vimrc"
      > user exrc file: "$HOME/.exrc"
      > system gvimrc file: "$VIM/gvimrc"
      > user gvimrc file: "$HOME/.gvimrc"
      > system menu file: "$VIMRUNTIME/menu.vim"
      > fall-back for $VIM: "/usr/local/share/vim"
      > Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
      > -I/usr/local/include/ gtk-1.2 -I/usr/local/include/glib-1.2
      > -I/usr/local/lib/glib/include -I/usr/include/X1 1R6 -O
      > Linking: gcc -o vim -L/usr/local/lib -lgtk -lgdk -lgmodule
      > -lglib
      > -lintl -lXext -lm -lXt -lX11 -lncurses
      >
      >
      > Thansk a lot for your advice.
      >
      > Malte

      Xavier...



      __________________________________________________________________
      Introducing the New Netscape Internet Service.
      Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

      Netscape. Just the Net You Need.

      New! Netscape Toolbar for Internet Explorer
      Search from anywhere on the Web and block those annoying pop-ups.
      Download now at http://channels.netscape.com/ns/search/install.jsp
    • Malte Neumann
      ... This happens using gvim. I just tried it on a plain terminal (xterm) and got the following results: 1. setting breakpoint: Started VimGDB, initialize gdb
      Message 2 of 19 , Mar 24, 2004
      • 0 Attachment
        On Wed, Mar 24, 2004 at 09:31:46AM -0500, Xavier de Gaye wrote:
        >
        > On Wed, 17 Mar 2004 Malte Neumann wrote:
        > > Hi,
        > >
        > > I am trying to use the VimGDB interface. Reading the manual it looks exactly
        > > like what I was looking for a long time...
        > >

        ...

        > > Now I have still have another small problem:
        > >
        > > Starting gdb and sending commands to gdb works very well. I can load a file
        > > set the arguments and run it. But when I try to set a breakpoint with e.g.
        > >
        > > :call gdb("break fluid3")
        > >
        > > gdb registers the breakpoint, but the corresponding file is not displayed.
        > > The status line shows the correct file name and number of lines etc. but the
        > > content of the file is not show and vim hangs and has to be killed. The same
        > >
        > Does this happen with vim on a plain terminal (rxvt) or with gvim,
        > or with both ?

        This happens using gvim.
        I just tried it on a plain terminal (xterm) and got the following results:

        1. setting breakpoint:
        Started VimGDB, initialize gdb and set the exe file, call the gdb command
        'break fluid3' gives the result:

        Pid 28393 was killed due to stack growth failure.
        Possible causes: insufficient memory or swap, or stack size exceeded maxssize.

        Pid 28393 was killed due to failure in writing the signal context.
        Segmentation fault (core dumped)

        2. editing a file:
        Started VimGDB, initialize gdb, edit a source file with ':e src/f3_main.c'
        gives the result:
        vim is locked and uses 96% cpu.
        Attaching to the locked vim process (debug exe) does not work, gdb just says:
        (gdb) attach 3646
        Attaching to process 3646

        and hangs as well.

        >
        > What happens if you first edit the source file where fluid3() is
        > defined and then set the breakpoint ?
        >
        > Also, if this occurs systematically and you don't mind compiling the
        > whole Vim source code with -g, you could start a plain GDB process
        > in another terminal once VimGDB is locked, and then run the GDB command
        > "attach VimGDB_pid" and send me the backtrace. This would help a lot.
        > To recompile Vim with -g, uncomment "#CFLAGS = -g" in the Makefile and
        > then do "make reconfig".
        >
        > > content of the file is not show and vim hangs and has to be killed. The same
        > > thing happens when opening a source file with :e.
        > >
        > Does the last sentence means that after setting the breakpoint, you
        > cannot edit any file, or is it also after starting gdb ?
        >
        >
        > >
        > > Sometimes vim even crashes when sourcing the gdb_mappings.vim file.
        > > Running the core file in gdb gives the following information:
        > >
        > > Program terminated with signal 11, Segmentation fault.
        > > Unable to find __dld_flags symbol in object file.
        > >
        > Can you get a backtrace of this (same procedure as above, only you
        > attach before the crash, before sourcing the gdb_mappings.vim file) ?

        I started VimGDB and attached gdb to the running process and the sourced
        gdb_mappings.vim.

        The result in vim:
        :run ~/.vim/macros/gdb_mappings.vim
        Pid 3664 was killed due to stack growth failure.
        Possible causes: insufficient memory or swap, or stack size exceeded maxssize.

        Pid 3664 was killed due to failure in writing the signal context.
        Segmentation fault (core dumped)

        The result in gdb:
        (gdb) cont
        Continuing.
        ttrace wait: No such process.
        << here vim exited
        (gdb) up
        No stack.
        (gdb)

        How can I get a backtrace??

        > I am running Linux here. To get Vim to run with poll() and not using
        > gettimeofday() so as to get closer to your setup, I compiled Vim after
        > commenting out in auto/config.h:
        >
        > //#define HAVE_GETTIMEOFDAY 1
        > //#define HAVE_SELECT 1
        >
        > This version of VimGDB using poll() runs fine in plain terminal mode
        > on Linux as far as I can tell.
        >
        > However it does run badly in GUI mode (gvim). It does not hang as you
        > are reporting on HP-UX, but the first keystroke after any
        > ":call gdb(...)" is ignored and only shows up after a second keystroke.

        I noticed this bug as well.

        >
        > The bug is in VimGDB handling of the last two nested loops in
        > gui_wait_for_chars() in gui.c:
        >
        > the last before last loop (a) starts with:
        > 2642: while ((retval = gui_mch_wait_for_chars(wtime)) == FAIL)
        > the last loop (b) is nested within the previous loop (a) and starts
        > with:
        > 2680: for (;;)
        >
        > When gui_mch_wait_for_chars(-1L) returns with OK in the last nested
        > loop (b), a break statement is missing and we should exit both loops
        > instead of doing a new iteration in loop (a). Even worse, this new
        > iteration in loop (a) may cause gui_mch_wait_for_chars() to be invoked
        > with wtime == 0 !
        >
        > This does also occur when VimGDB is compiled with select() and
        > gettimeofday() but is not so obvious to the user. The difference
        > between both behaviour stems from the fact that with poll (and without
        > gettimeofday), the computation of the estimation of the remaining wtime
        > returned by gdb_process_output is gross and way too large (the
        > second bug).
        >
        > Both these bugs above lead to the two following fixes and solve the
        > problem on my Linux box here.
        >
        ...
        >
        > I am afraid this will not solve the problem on HP-UX. For the
        > case it does, it would be very helpful if you applied first the fix in
        > gui.c, test it and then apply the fix in gdb.c and test it again.
        > The reason for doing that is that the second fix in gdb.c might only
        > hide the bug (if it does) and it's good to know.
        >

        I applied the patches one by one:
        The first one fixed the problem with the first keystroke after any
        ":call gdb(...)" call.
        The second did not make any noticable changes.

        Thanks a lot for your help.

        Malte

        --
        --------------------------------------------------------------------------
        Malte Neumann
        --------------------------------------------------------------------------
        Institut fuer Baustatik / Institute of Structural Mechanics
        Prof. Dr.-Ing. Ekkehard Ramm
        Universitaet Stuttgart / University of Stuttgart

        Pfaffenwaldring 7, D-70550 Stuttgart, Germany

        mailto:neumann@...-stuttgart.de phone: ++49-711-685-6121
        http://www.uni-stuttgart.de/ibs/members/neumann/ fax: ++49-711-685-6130
        --------------------------------------------------------------------------
      • Xavier de Gaye
        ... [...] ... Let s keep using the last test case 2. editing a file . ... [...] ... I think the stack is corrupted. A backtrace is constructed from examining
        Message 3 of 19 , Mar 31, 2004
        • 0 Attachment
          On Wed, 24 Mar 2004, Malte Neumann wrote:

          > On Wed, Mar 24, 2004 at 09:31:46AM -0500, Xavier de Gaye wrote:
          > > On Wed, 17 Mar 2004 Malte Neumann wrote:

          [...]

          > I just tried it on a plain terminal (xterm) and got the following results:
          >
          > 1. setting breakpoint:
          > Started VimGDB, initialize gdb and set the exe file, call the gdb command
          > 'break fluid3' gives the result:
          >
          > Pid 28393 was killed due to stack growth failure.
          > Possible causes: insufficient memory or swap, or stack size exceeded maxssize.
          >
          > Pid 28393 was killed due to failure in writing the signal context.
          > Segmentation fault (core dumped)
          >
          > 2. editing a file:
          > Started VimGDB, initialize gdb, edit a source file with ':e src/f3_main.c'
          > gives the result:
          > vim is locked and uses 96% cpu.
          > Attaching to the locked vim process (debug exe) does not work, gdb just says:
          > (gdb) attach 3646
          > Attaching to process 3646
          >
          > and hangs as well.
          >

          Let's keep using the last test case "2. editing a file".

          >
          > I started VimGDB and attached gdb to the running process and the sourced
          > gdb_mappings.vim.
          >
          > The result in vim:
          > :run ~/.vim/macros/gdb_mappings.vim
          > Pid 3664 was killed due to stack growth failure.
          > Possible causes: insufficient memory or swap, or stack size exceeded maxssize.
          >
          > Pid 3664 was killed due to failure in writing the signal context.
          > Segmentation fault (core dumped)
          >
          > The result in gdb:
          > (gdb) cont
          > Continuing.
          > ttrace wait: No such process.
          [...]
          > (gdb) up
          > No stack.
          > (gdb)
          >
          > How can I get a backtrace??
          >

          I think the stack is corrupted. A backtrace is constructed from
          examining the stack. If it's corrupted, no backtrace can be built
          from it. That would also explain why GDB hangs in the other case.


          > > I am running Linux here. To get Vim to run with poll() and not using
          > > gettimeofday() so as to get closer to your setup, I compiled Vim after
          > > commenting out in auto/config.h:
          > >
          > > //#define HAVE_GETTIMEOFDAY 1
          > > //#define HAVE_SELECT 1

          [...]

          > > I am afraid this will not solve the problem on HP-UX. For the
          > > case it does, it would be very helpful if you applied first the fix in
          > > gui.c, test it and then apply the fix in gdb.c and test it again.
          > > The reason for doing that is that the second fix in gdb.c might only
          > > hide the bug (if it does) and it's good to know.
          > >
          >
          > I applied the patches one by one:
          > The first one fixed the problem with the first keystroke after any
          > ":call gdb(...)" call.
          > The second did not make any noticable changes.
          >
          > Thanks a lot for your help.
          >
          > Malte

          In gdb.c, function read_gdb(), a local array is defined as:

          gdb.c: struct pollfd fds[1];

          The compiler gives a warning, when poll() is called in
          read_gdb() at:

          os_unix.c:4185 ret = poll(&fds, nfd, (int)msec);

          The first argument of poll() should be "fds", not "&fds".
          HP-UX is a RISC architecture and compiling on these is
          tricky sometimes. Let's do the things right and please
          try after replacing the above line with:

          gdb.c:4822 if ((rc = poll(fds, 1, wtime)) > 0)

          Anyway, the next step can be trying to track the other differences
          between both systems: can you send me your auto/config.h so that I
          may check that.

          Another point about the compiler. You are using gcc. From Vim's
          Makefile, it seems that c89 is the compiler that has been tested
          on HP-UX when compiling Vim. I don't mean to switch to c89, I
          am just curious.

          Maybe you could run "make test" from vim62/src to validate Vim
          compilation. See the Makefile.

          Xavier...



          __________________________________________________________________
          Introducing the New Netscape Internet Service.
          Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

          Netscape. Just the Net You Need.

          New! Netscape Toolbar for Internet Explorer
          Search from anywhere on the Web and block those annoying pop-ups.
          Download now at http://channels.netscape.com/ns/search/install.jsp
        • Malte Neumann
          ... I have already tried Version 6, and I believe there this problem was fixed. ... I attached the auto/config.h ... I don t know c89, the HP c-compiler in
          Message 4 of 19 , Mar 31, 2004
          • 0 Attachment
            On Wed, Mar 31, 2004 at 07:36:59AM -0500, Xavier de Gaye wrote:
            >
            > On Wed, 24 Mar 2004, Malte Neumann wrote:
            >
            > > On Wed, Mar 24, 2004 at 09:31:46AM -0500, Xavier de Gaye wrote:
            > > > On Wed, 17 Mar 2004 Malte Neumann wrote:
            >
            > [...]
            >
            > > [...]
            > >
            >
            > Let's keep using the last test case "2. editing a file".
            >
            > >
            > > I started VimGDB and attached gdb to the running process and the sourced
            > > gdb_mappings.vim.
            > >
            > > The result in vim:
            > > :run ~/.vim/macros/gdb_mappings.vim
            > > Pid 3664 was killed due to stack growth failure.
            > > Possible causes: insufficient memory or swap, or stack size exceeded maxssize.
            > >
            > > Pid 3664 was killed due to failure in writing the signal context.
            > > Segmentation fault (core dumped)
            > >
            > > The result in gdb:
            > > (gdb) cont
            > > Continuing.
            > > ttrace wait: No such process.
            > [...]
            > > (gdb) up
            > > No stack.
            > > (gdb)
            > >
            > > How can I get a backtrace??
            > >
            >
            > I think the stack is corrupted. A backtrace is constructed from
            > examining the stack. If it's corrupted, no backtrace can be built
            > from it. That would also explain why GDB hangs in the other case.
            >
            > > > [...]
            > >
            > > I applied the patches one by one:
            > > The first one fixed the problem with the first keystroke after any
            > > ":call gdb(...)" call.
            > > The second did not make any noticable changes.
            > >
            > > Thanks a lot for your help.
            > >
            > > Malte
            >
            > In gdb.c, function read_gdb(), a local array is defined as:
            >
            > gdb.c: struct pollfd fds[1];
            >
            > The compiler gives a warning, when poll() is called in
            > read_gdb() at:
            >
            > os_unix.c:4185 ret = poll(&fds, nfd, (int)msec);
            >
            > The first argument of poll() should be "fds", not "&fds".
            > HP-UX is a RISC architecture and compiling on these is
            > tricky sometimes. Let's do the things right and please
            > try after replacing the above line with:
            >
            > gdb.c:4822 if ((rc = poll(fds, 1, wtime)) > 0)

            I have already tried Version 6, and I believe there this problem was fixed.

            >
            > Anyway, the next step can be trying to track the other differences
            > between both systems: can you send me your auto/config.h so that I
            > may check that.

            I attached the auto/config.h

            > Another point about the compiler. You are using gcc. From Vim's
            > Makefile, it seems that c89 is the compiler that has been tested
            > on HP-UX when compiling Vim. I don't mean to switch to c89, I
            > am just curious.

            I don't know c89, the HP c-compiler in HP-UX 11.0 is called 'cc' (it's the
            same name for HP-UX 10.20). But I think in the past I didn't manage to
            compile vim with this compiler and started to use gcc.

            >
            > Maybe you could run "make test" from vim62/src to validate Vim
            > compilation. See the Makefile.

            'make test' in vim62/src runs well for a while, but then stops with this
            error message:

            :/start of testfile/,/end of testfile/w! Xtestfile.gz
            Pid 2791 was killed due to stack growth failure.
            Possible causes: insufficient memory or swap, or stack size exceeded maxssize.

            Pid 2791 was killed due to failure in writing the signal context.
            *** Termination signal 139

            Stop.
            *** Error exit code 1

            Stop.

            -----------------------------

            I tried a little and found the following, partly confusing (to me), facts.
            Maybe they are helpful to you:

            - Only editing a c-file, w/o sourcing the mappings or strating gdb causes
            gdbvim to crash.

            - Editing a non c-file (e.g. a Makefile or a fortran-file) works.

            - Editing a c-file in the vim62/src directory works, it is also possible to
            start gdb on 'vim' an set a breakpoint using <C-B>.

            - Editing a vim-c-file (e.g. gdb.c or os_unix.c) in a directory other than
            vim62/src causes gdbvim to crash.

            Some time later ...

            After some further testing I found the following:
            - Everything (as far as I have tried) works fine when I remove the line
            "syn on" from my .vimrc.


            I hope these information help a little.

            Regards

            Malte

            --
            --------------------------------------------------------------------------
            Malte Neumann
            --------------------------------------------------------------------------
            Institut fuer Baustatik / Institute of Structural Mechanics
            Prof. Dr.-Ing. Ekkehard Ramm
            Universitaet Stuttgart / University of Stuttgart

            Pfaffenwaldring 7, D-70550 Stuttgart, Germany

            mailto:neumann@...-stuttgart.de phone: ++49-711-685-6121
            http://www.uni-stuttgart.de/ibs/members/neumann/ fax: ++49-711-685-6130
            --------------------------------------------------------------------------
          • Malte Neumann
            Hi Xavier, probably forgot to attach it... Malte PS: I m on holiday for the next 10 days, so no further tests possible. ... -- ... Malte Neumann ... Institut
            Message 5 of 19 , Apr 2, 2004
            • 0 Attachment
              Hi Xavier,

              probably forgot to attach it...

              Malte


              PS: I'm on holiday for the next 10 days, so no further tests possible.


              On Fri, Apr 02, 2004 at 09:00:06AM -0500, Xavier de Gaye wrote:
              >
              > Hi Malte,
              >
              > thanks for your mails
              > I didn't get your auto/config.h
              >
              > Xavier...
              >
              > Malte Neumann <neumann@...-stuttgart.de> wrote:
              >
              > >On Wed, Mar 31, 2004 at 07:36:59AM -0500, Xavier de Gaye wrote:
              > >>
              > >> On Wed, 24 Mar 2004, Malte Neumann wrote:
              > >>
              > >> > On Wed, Mar 24, 2004 at 09:31:46AM -0500, Xavier de Gaye wrote:
              > >> > > On Wed, 17 Mar 2004 Malte Neumann wrote:
              > >>
              > >> [...]
              > >>
              > >> > [...]
              > >> >
              > >>
              > >> Let's keep using the last test case "2. editing a file".
              > >>
              > >> >
              > >> > I started VimGDB and attached gdb to the running process and the sourced
              > >> > gdb_mappings.vim.
              > >> >
              > >> > The result in vim:
              > >> > :run ~/.vim/macros/gdb_mappings.vim
              > >> > Pid 3664 was killed due to stack growth failure.
              > >> > Possible causes: insufficient memory or swap, or stack size exceeded maxssize.
              > >> >
              > >> > Pid 3664 was killed due to failure in writing the signal context.
              > >> > Segmentation fault (core dumped)
              > >> >
              > >> > The result in gdb:
              > >> > (gdb) cont
              > >> > Continuing.
              > >> > ttrace wait: No such process.
              > >> [...]
              > >> > (gdb) up
              > >> > No stack.
              > >> > (gdb)
              > >> >
              > >> > How can I get a backtrace??
              > >> >
              > >>
              > >> I think the stack is corrupted. A backtrace is constructed from
              > >> examining the stack. If it's corrupted, no backtrace can be built
              > >> from it. That would also explain why GDB hangs in the other case.
              > >>
              > >> > > [...]
              > >> >
              > >> > I applied the patches one by one:
              > >> > The first one fixed the problem with the first keystroke after any
              > >> > ":call gdb(...)" call.
              > >> > The second did not make any noticable changes.
              > >> >
              > >> > Thanks a lot for your help.
              > >> >
              > >> > Malte
              > >>
              > >> In gdb.c, function read_gdb(), a local array is defined as:
              > >>
              > >>     gdb.c: struct pollfd   fds[1];
              > >>
              > >> The compiler gives a warning, when poll() is called in
              > >> read_gdb() at:
              > >>
              > >>     os_unix.c:4185  ret = poll(&fds, nfd, (int)msec);
              > >>
              > >> The first argument of poll() should be "fds", not "&fds".
              > >> HP-UX is a RISC architecture and compiling on these is
              > >> tricky sometimes. Let's do the things right and please
              > >> try after replacing the above line with:
              > >>
              > >>     gdb.c:4822      if ((rc = poll(fds, 1, wtime)) > 0)
              > >
              > >I have already tried Version 6, and I believe there this problem was fixed.
              > >
              > >>
              > >> Anyway, the next step can be trying to track the other differences
              > >> between both systems: can you send me your auto/config.h so that I
              > >> may check that.
              > >
              > >I attached the auto/config.h
              > >
              > >> Another point about the compiler. You are using gcc. From Vim's
              > >> Makefile, it seems that c89 is the compiler that has been tested
              > >> on HP-UX when compiling Vim. I don't mean to switch to c89, I
              > >> am just curious.
              > >
              > >I don't know c89, the HP c-compiler in HP-UX 11.0 is called 'cc' (it's the
              > >same name for HP-UX 10.20).  But I think in the past I didn't manage to
              > >compile vim with this compiler and started to use gcc.
              > >
              > >>
              > >> Maybe you could run "make test" from vim62/src to validate Vim
              > >> compilation. See the Makefile.
              > >
              > >'make test' in vim62/src runs well for a while, but then stops with this
              > >error message:
              > >
              > >:/start of testfile/,/end of testfile/w! Xtestfile.gz
              > >Pid 2791 was killed due to stack growth failure.
              > >Possible causes: insufficient memory or swap, or stack size exceeded maxssize.
              > >
              > >Pid 2791 was killed due to failure in writing the signal context.
              > >*** Termination signal 139
              > >
              > >Stop.
              > >*** Error exit code 1
              > >
              > >Stop.
              > >
              > >-----------------------------
              > >
              > >I tried a little and found the following, partly confusing (to me), facts.
              > >Maybe they are helpful to you:
              > >
              > >- Only editing a c-file, w/o sourcing the mappings or strating gdb causes
              > >  gdbvim to crash.
              > >
              > >- Editing a non c-file (e.g. a Makefile or a fortran-file) works.
              > >
              > >- Editing a c-file in the vim62/src directory works, it is also possible to
              > >  start gdb on 'vim' an set a breakpoint using <C-B>.
              > >
              > >- Editing a vim-c-file (e.g. gdb.c or os_unix.c) in a directory other than
              > >  vim62/src causes gdbvim to crash.
              > >
              > >Some time later ...
              > >
              > >After some further testing I found the following:
              > >- Everything (as far as I have tried) works fine when I remove the line
              > >  "syn on" from my .vimrc.
              > >
              > >
              > >I hope these information help a little.
              > >
              > >Regards
              > >
              > >Malte
              > >
              > >--
              > >--------------------------------------------------------------------------
              > >                              Malte Neumann
              > >--------------------------------------------------------------------------
              > >Institut fuer Baustatik / Institute of Structural Mechanics      
              > >Prof. Dr.-Ing. Ekkehard Ramm                        
              > >Universitaet Stuttgart / University of Stuttgart          
              > >                                
              > >Pfaffenwaldring 7, D-70550 Stuttgart, Germany
              > >
              > >mailto:neumann@...-stuttgart.de            phone: ++49-711-685-6121
              > >http://www.uni-stuttgart.de/ibs/members/neumann/  fax:   ++49-711-685-6130
              > >--------------------------------------------------------------------------
              > >
              >
              > __________________________________________________________________
              > Introducing the New Netscape Internet Service.
              > Only $9.95 a month -- Sign up today at http://isp.netscape.com/register
              >
              > Netscape. Just the Net You Need.
              >
              > New! Netscape Toolbar for Internet Explorer
              > Search from anywhere on the Web and block those annoying pop-ups.
              > Download now at http://channels.netscape.com/ns/search/install.jsp

              --
              --------------------------------------------------------------------------
              Malte Neumann
              --------------------------------------------------------------------------
              Institut fuer Baustatik / Institute of Structural Mechanics
              Prof. Dr.-Ing. Ekkehard Ramm
              Universitaet Stuttgart / University of Stuttgart

              Pfaffenwaldring 7, D-70550 Stuttgart, Germany

              mailto:neumann@...-stuttgart.de phone: ++49-711-685-6121
              http://www.uni-stuttgart.de/ibs/members/neumann/ fax: ++49-711-685-6130
              --------------------------------------------------------------------------
            • Xavier de Gaye
              ... Yes, you are right, that was fixed in patch 6. ... What version of Vim had you compiled in the past with gcc ? ... It crashes in test11.in: Tests for
              Message 6 of 19 , Apr 5, 2004
              • 0 Attachment
                On Wed, 31 Mar 2004, Malte Neumann wrote:

                > [...]
                >
                > > The first argument of poll() should be "fds", not "&fds".
                > > HP-UX is a RISC architecture and compiling on these is
                > > tricky sometimes. Let's do the things right and please
                > > try after replacing the above line with:
                > >
                > > gdb.c:4822 if ((rc = poll(fds, 1, wtime)) > 0)
                >
                > I have already tried Version 6, and I believe there this problem was
                > fixed.
                >

                Yes, you are right, that was fixed in patch 6.


                > [...]
                >
                > > Another point about the compiler. You are using gcc. From Vim's
                > > Makefile, it seems that c89 is the compiler that has been tested
                > > on HP-UX when compiling Vim. I don't mean to switch to c89, I
                > > am just curious.
                >
                > I don't know c89, the HP c-compiler in HP-UX 11.0 is called 'cc' (it's the
                > same name for HP-UX 10.20). But I think in the past I didn't manage to
                > compile vim with this compiler and started to use gcc.
                >

                What version of Vim had you compiled in the past with gcc ?


                > >
                > > Maybe you could run "make test" from vim62/src to validate Vim
                > > compilation. See the Makefile.
                >
                > 'make test' in vim62/src runs well for a while, but then stops with this
                > error message:
                >
                > :/start of testfile/,/end of testfile/w! Xtestfile.gz
                > Pid 2791 was killed due to stack growth failure.
                > Possible causes: insufficient memory or swap, or stack size exceeded
                > maxssize.
                >
                > Pid 2791 was killed due to failure in writing the signal context.
                > *** Termination signal 139
                >
                > Stop.
                > *** Error exit code 1
                >
                > Stop.
                >

                It crashes in test11.in: "Tests for autocommands"
                It looks like the same type of crash as the other ones.


                > -----------------------------
                >
                > I tried a little and found the following, partly confusing (to me), facts.
                > Maybe they are helpful to you:
                >
                > - Only editing a c-file, w/o sourcing the mappings or strating gdb causes
                > gdbvim to crash.
                >

                As long as (gdb() is not called) GDB is not started in a Vim
                session, no VimGDB code is involved except one malloc, and
                tests on gdb state that all return "not ready". So it seems
                from this test and "make test" that VimGDB is not involved.


                > - Editing a non c-file (e.g. a Makefile or a fortran-file) works.
                >
                > - Editing a c-file in the vim62/src directory works, it is also possible to
                > start gdb on 'vim' an set a breakpoint using <C-B>.
                >

                Do you mean that it works when files are local to the current
                directory (and that you are running ./vim in vim62/src) ?


                > - Editing a vim-c-file (e.g. gdb.c or os_unix.c) in a directory other than
                > vim62/src causes gdbvim to crash.
                >
                > Some time later ...
                >
                > After some further testing I found the following:
                > - Everything (as far as I have tried) works fine when I remove the line
                > "syn on" from my .vimrc.
                >

                Interesting, but I don't know what that means except that syntax
                files are maybe not opened then (and the pbm may lie with opening
                files, refer to "make test" crash)

                Maybe try by renaming your .vimrc to something else (so it is not
                sourced), then run Vim, type ":syntax enable" and do the test
                "Only editing a c-file, w/o sourcing the mappings or strating gdb"

                >
                > I hope these information help a little.
                >

                Yes it does, this is good.


                > Regards
                >
                > Malte
                >
                > --

                I think it is important to validate Vim62 compilation with
                gcc on your system. Could you compile the stock Vim62 without
                the VimGDB patch and run again "make test" and also the test
                that crashed with "Only editing a c-file, w/o sourcing the
                mappings" and "syn on" in your .vimrc.

                Both should crash I think. If this is the case it will be
                interesting to know the differences with the previous
                compilation of Vim with gcc that was Ok. Maybe it would
                be worth giving another try compiling Vim62 with 'cc'
                instead of gcc then.

                Xavier...



                __________________________________________________________________
                Introducing the New Netscape Internet Service.
                Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

                Netscape. Just the Net You Need.

                New! Netscape Toolbar for Internet Explorer
                Search from anywhere on the Web and block those annoying pop-ups.
                Download now at http://channels.netscape.com/ns/search/install.jsp
              • Malte Neumann
                ... [...] ... My standard Vim installation is at the moment 6.2.106. But I had several others before (mainly 6.1.xxx). VIM - Vi IMproved 6.2 (2003 Jun 1,
                Message 7 of 19 , Apr 13, 2004
                • 0 Attachment
                  On Mon, Apr 05, 2004 at 08:53:42AM -0400, Xavier de Gaye wrote:
                  >
                  > On Wed, 31 Mar 2004, Malte Neumann wrote:

                  [...]

                  > > > Another point about the compiler. You are using gcc. From Vim's
                  > > > Makefile, it seems that c89 is the compiler that has been tested
                  > > > on HP-UX when compiling Vim. I don't mean to switch to c89, I
                  > > > am just curious.
                  > >
                  > > I don't know c89, the HP c-compiler in HP-UX 11.0 is called 'cc' (it's
                  > > the same name for HP-UX 10.20). But I think in the past I didn't manage
                  > > to compile vim with this compiler and started to use gcc.
                  > >
                  >
                  > What version of Vim had you compiled in the past with gcc ?

                  My standard Vim installation is at the moment 6.2.106. But I had several
                  others before (mainly 6.1.xxx).

                  VIM - Vi IMproved 6.2 (2003 Jun 1, compiled Oct 14 2003 08:54:12)
                  Included patches: 1-106
                  Compiled by neumann@stat38
                  Normal version with GTK GUI. Features included (+) or not (-): -arabic
                  +autocmd +balloon_eval +browse +builtin_terms +byte_offset +cindent
                  +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
                  +comments +cryptv +cscope +dialog_con_gui +diff +digraphs +dnd -ebcdic
                  -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path
                  +find_in_path +folding -footer +fork() +gettext -hangul_input -iconv
                  +insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent
                  +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape
                  -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm +mouse_xterm
                  -multi_byte +multi_lang +netbeans_intg -osfiletype +path_extra -perl
                  +postscript +printer -python +quickfix -rightleft -ruby +scrollbind +signs
                  +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
                  +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects
                  +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra
                  +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11
                  -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save
                  system vimrc file: "$VIM/vimrc"
                  user vimrc file: "$HOME/.vimrc"
                  user exrc file: "$HOME/.exrc"
                  system gvimrc file: "$VIM/gvimrc"
                  user gvimrc file: "$HOME/.gvimrc"
                  system menu file: "$VIMRUNTIME/menu.vim"
                  fall-back for $VIM: "/usr/local//share/vim"
                  Compilation: gcc -c -I. -Iproto -I. -DHAVE_CONFIG_H -DFEAT_GUI_GTK
                  -I/usr/local/include/gtk-1.2 -I/usr/local/include/glib-1.2
                  -I/usr/local/lib/glib/include -I/usr/includ e/X11R6 -g -O2
                  -fno-strength-reduce
                  Linking: gcc -o vim -L/usr/local/lib -lgtk -lgdk -lgmodule -lglib
                  -lintl -lXex t -lm -lXt -lX11 -lncurses -lnsl -lintl

                  > > >
                  > > > Maybe you could run "make test" from vim62/src to validate Vim
                  > > > compilation. See the Makefile.
                  > >
                  > > 'make test' in vim62/src runs well for a while, but then stops with this
                  > > error message:
                  > >
                  > > :/start of testfile/,/end of testfile/w! Xtestfile.gz
                  > > Pid 2791 was killed due to stack growth failure.
                  > > Possible causes: insufficient memory or swap, or stack size exceeded
                  > > maxssize.
                  > >
                  > > Pid 2791 was killed due to failure in writing the signal context.
                  > > *** Termination signal 139
                  > >
                  > > Stop.
                  > > *** Error exit code 1
                  > >
                  > > Stop.
                  > >
                  >
                  > It crashes in test11.in: "Tests for autocommands"
                  > It looks like the same type of crash as the other ones.
                  >
                  >
                  > > -----------------------------
                  > >
                  > > I tried a little and found the following, partly confusing (to me),
                  > > facts.
                  > > Maybe they are helpful to you:
                  > >
                  > > - Only editing a c-file, w/o sourcing the mappings or strating gdb causes
                  > > gdbvim to crash.
                  > >
                  >
                  > As long as (gdb() is not called) GDB is not started in a Vim
                  > session, no VimGDB code is involved except one malloc, and
                  > tests on gdb state that all return "not ready". So it seems
                  > from this test and "make test" that VimGDB is not involved.
                  >
                  >
                  > > - Editing a non c-file (e.g. a Makefile or a fortran-file) works.
                  > >
                  > > - Editing a c-file in the vim62/src directory works, it is also possible
                  > > to start gdb on 'vim' an set a breakpoint using <C-B>.
                  > >
                  >
                  > Do you mean that it works when files are local to the current
                  > directory (and that you are running ./vim in vim62/src) ?

                  I am always running the installed gdbvim executable from my home directory.
                  Opening the files as follows (all with :syntax enable):

                  :e ~/long_path_to_my_vim_sources/vim62/src/os_unix.c WORKS

                  my own c-file:
                  :e ~/wdir/ccarat_repos/src/main/main_ccarat.c FAILS

                  os_unix.c copied to my directory:
                  :e ~/wdir/ccarat_repos/src/main/os_unix.c FAILS


                  > > - Editing a vim-c-file (e.g. gdb.c or os_unix.c) in a directory other
                  > > than vim62/src causes gdbvim to crash.
                  > >
                  > > Some time later ...
                  > >
                  > > After some further testing I found the following:
                  > > - Everything (as far as I have tried) works fine when I remove the line
                  > > "syn on" from my .vimrc.
                  > >
                  >
                  > Interesting, but I don't know what that means except that syntax
                  > files are maybe not opened then (and the pbm may lie with opening
                  > files, refer to "make test" crash)
                  >
                  > Maybe try by renaming your .vimrc to something else (so it is not
                  > sourced), then run Vim, type ":syntax enable" and do the test
                  > "Only editing a c-file, w/o sourcing the mappings or strating gdb"

                  Same behaviour as above.

                  [...]

                  > I think it is important to validate Vim62 compilation with
                  > gcc on your system. Could you compile the stock Vim62 without
                  > the VimGDB patch and run again "make test" and also the test
                  > that crashed with "Only editing a c-file, w/o sourcing the
                  > mappings" and "syn on" in your .vimrc.

                  I just compiled a pure Vim 6.2 (no patches) with gcc. Here the :version:

                  VIM - Vi IMproved 6.2 (2003 Jun 1, compiled Apr 13 2004 09:07:15)
                  Compiled by neumann@stat38
                  Normal version with GTK GUI. Features included (+) or not (-): -arabic
                  +autocmd +balloon_eval +browse +builtin_terms +byte_offset +cindent
                  +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
                  +comments +cryptv +cscope +dialog_con_gui +diff +digraphs +dnd -ebcdic
                  -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path
                  +find_in_path +folding -footer +fork() -gettext -hangul_input -iconv
                  +insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent
                  +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape
                  -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm +mouse_xterm
                  -multi_byte +multi_lang +netbeans_intg -osfiletype +path_extra -perl
                  +postscript +printer -python +quickfix -rightleft -ruby +scrollbind +signs
                  +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
                  +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects
                  +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra
                  +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11
                  -xfontset +xim -xsmp +xterm_clipboard -xterm_save
                  system vimrc file: "$VIM/vimrc"
                  user vimrc file: "$HOME/.vimrc"
                  user exrc file: "$HOME/.exrc"
                  system gvimrc file: "$VIM/gvimrc"
                  user gvimrc file: "$HOME/.gvimrc"
                  system menu file: "$VIMRUNTIME/menu.vim"
                  fall-back for $VIM: "/usr/local/share/vim"
                  Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
                  -I/usr/local/include gtk-1.2 -I/usr/local/include/glib-1.2
                  -I/usr/local/lib/glib/include -I/usr/include/X/ 1R6 -O 1
                  Linking: gcc -o vim -L/usr/local/lib -lgtk -lgdk -lgmodule -lglib
                  -lintl -lXext -lm -lXt -lX11 -lncurses


                  "make check" does NOT crash an gives the following result:
                  Test results:
                  test18 FAILED
                  test32 FAILED
                  ALL DONE


                  > Both should crash I think. If this is the case it will be
                  > interesting to know the differences with the previous
                  > compilation of Vim with gcc that was Ok. Maybe it would
                  > be worth giving another try compiling Vim62 with 'cc'
                  > instead of gcc then.

                  I tried twice with cc, once with gui and once w/o gui.
                  The first try (with gui, i.e. no changes in the configuration) compiled
                  fine, but failed while linking with unsatisfied symbols:

                  /usr/ccs/bin/ld: Unsatisfied symbols:
                  XpmReadFileToImage (first referenced in objects/gui_x11.o) (code)
                  XpmCreatePixmapFromData (first referenced in objects/gui_motif.o) (code)
                  XpmFreeAttributes (first referenced in objects/gui_x11.o) (code)
                  XpmReadFileToPixmap (first referenced in objects/gui_x11.o) (code)
                  *** Error exit code 1


                  The second try w/o gui compiled and linked ok for the pure vim 6.2 and for
                  the gdbvim (patch6).
                  But the gdbvim shows the same problem as the one compiled with gcc. It
                  crashes when opening a file with ":syntax enable". The pure vim 6.2 works
                  fine again.


                  regards

                  Malte

                  --
                  --------------------------------------------------------------------------
                  Malte Neumann
                  --------------------------------------------------------------------------
                  Institut fuer Baustatik / Institute of Structural Mechanics
                  Prof. Dr.-Ing. Ekkehard Ramm
                  Universitaet Stuttgart / University of Stuttgart

                  Pfaffenwaldring 7, D-70550 Stuttgart, Germany

                  mailto:neumann@...-stuttgart.de phone: ++49-711-685-6121
                  http://www.uni-stuttgart.de/ibs/members/neumann/ fax: ++49-711-685-6130
                  --------------------------------------------------------------------------
                • Xavier de Gaye
                  Hi Malte, To sum up: The stock Vim62 runs fine on your system. VimGDB compiled with same compiler crashes when (among other cases): a) make test is run b)
                  Message 8 of 19 , Apr 14, 2004
                  • 0 Attachment
                    Hi Malte,

                    To sum up:

                    The stock Vim62 runs fine on your system.

                    VimGDB compiled with same compiler crashes when
                    (among other cases):
                    a) 'make test' is run
                    b) VimGDB opens some file and GDB has never been started
                    (VimGDB does not crash when .vimrc does not contain
                    ':syntax enable' and does not always crash when
                    opening files)

                    There are 3 differences in the way Vim62 and VimGDB are run.
                    Let's try to get from which comes the crash:
                    1 - VimGDB may use syntax files (gdb.vim and gdbvim.vim)
                    2 - VimGDB includes specific code to handle GDB
                    3 - VimGDB is compiled with a configure file built with
                    'make autoconf', not with the original one
                    4 - am I missing something...

                    1 - VimGDB may use syntax files (gdb.vim and gdbvim.vim)

                    I don't think the syntax files can be involved in the crash
                    when you run 'make test'. To make sure, try one of those
                    cases where VimGDB crashes after removing those syntax files.


                    2 - VimGDB includes specific code to handle GDB

                    When GDB is not started by VimGDB, the VimGDB specific code
                    does very little and I do not think it is involved. To make
                    sure, let's try to prevent ALL VimGDB code from being run:

                    a) Do not create the gdb_T structure:
                    In main.c, comment gdb_new() by replacing:

                    #ifdef FEAT_GDB
                    gdb = gdb_new();
                    #endif

                    with

                    #ifdef FEAT_GDB
                    /* gdb = gdb_new(); */
                    #endif

                    The 'gdb' pointer is NULL for the whole Vim session.
                    No VimGDB function can run without reading this structure.
                    No VimGDB specific code can be run from Vim code.


                    b) Do not instantiate VimGDB options
                    If VimGDB still crashes after previous step.
                    In option.c, at the top of the file, undefine FEAT_GDB, just
                    below the vim.h inclusion:

                    #define IN_OPTION_C
                    #include "vim.h"

                    #undef FEAT_GDB

                    VimGDB options are removed.


                    c) No VimGDB code in buffer.c
                    If VimGDB still crashes after previous step.
                    Same as previous step in buffer.c:

                    #include "vim.h"
                    #undef FEAT_GDB

                    The VimGDB code that is removed here, mostly does the same
                    thing that NetBeans does.


                    d) No VimGDB code in ex_getln.c
                    If VimGDB still crashes after previous step.
                    Same as previous step in ex_getln.c:

                    #include "vim.h"
                    #undef FEAT_GDB

                    After this step, all the code that has been changed in Vim62
                    by VimGDB are VimGDB functions calling VimGDB code with
                    a NULL gdb pointer.


                    3 - VimGDB is compiled with a configure file built with
                    'make autoconf'

                    If VimGDB still crashes after previous step.
                    To eliminate the cause of the crash as a bad configure file
                    built by 'make autoconf' during the installation of VimGDB,
                    let's use the original configure file from Vim62 distribution.

                    You have to start from scratch with a Vim62 source tar ball
                    and the VimGDB patch 6:

                    . apply VimGDB patch to a stock Vim62 source code
                    . do *NOT* run 'make autoconf'
                    . run 'make' and interrupt it after one or two source
                    files are compiled
                    . apply the changes to auto/config.h and auto/config.mk
                    described below
                    . run 'make' again to completion and test for crash

                    Add to end of auto/config.h:
                    #define FEAT_GDB 1

                    Add to end of auto/config.mk:
                    GDB_SRC = gdb.c gdb_lvl2.c gdb_lvl3.c pty.c
                    GDB_OBJ = objects/gdb.o objects/gdb_lvl2.o objects/gdb_lvl3.o objects/pty.o

                    Important notes:
                    I have tested that compilation here with VimGDB patch 6 and
                    no GUI (faster).
                    If you compile with the GUI (the default), do not include
                    'pty.c' and 'objects/pty.o' in GDB_SRC and GDB_OBJ as these
                    are already included in the GUI.
                    If you compile with VimGDB patch 5: do not include all gdb_lvl*


                    Xavier...



                    __________________________________________________________________
                    Introducing the New Netscape Internet Service.
                    Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

                    Netscape. Just the Net You Need.

                    New! Netscape Toolbar for Internet Explorer
                    Search from anywhere on the Web and block those annoying pop-ups.
                    Download now at http://channels.netscape.com/ns/search/install.jsp
                  • Malte Neumann
                    ... That s right. This is how I see the situation. ... I moved the whole syntax directory outside .vim, but gdbvim still crashes opening a file. ... No change
                    Message 9 of 19 , Apr 15, 2004
                    • 0 Attachment
                      On Wed, Apr 14, 2004 at 08:13:21AM -0400, Xavier de Gaye wrote:
                      >
                      > Hi Malte,
                      >
                      > To sum up:
                      >
                      > The stock Vim62 runs fine on your system.
                      >
                      > VimGDB compiled with same compiler crashes when
                      > (among other cases):
                      > a) 'make test' is run
                      > b) VimGDB opens some file and GDB has never been started
                      > (VimGDB does not crash when .vimrc does not contain
                      > ':syntax enable' and does not always crash when
                      > opening files)

                      That's right. This is how I see the situation.

                      > There are 3 differences in the way Vim62 and VimGDB are run.
                      > Let's try to get from which comes the crash:
                      > 1 - VimGDB may use syntax files (gdb.vim and gdbvim.vim)
                      > 2 - VimGDB includes specific code to handle GDB
                      > 3 - VimGDB is compiled with a configure file built with
                      > 'make autoconf', not with the original one
                      > 4 - am I missing something...
                      >
                      > 1 - VimGDB may use syntax files (gdb.vim and gdbvim.vim)
                      >
                      > I don't think the syntax files can be involved in the crash
                      > when you run 'make test'. To make sure, try one of those
                      > cases where VimGDB crashes after removing those syntax files.

                      I moved the whole syntax directory outside .vim, but gdbvim still crashes
                      opening a file.

                      > 2 - VimGDB includes specific code to handle GDB
                      >
                      > When GDB is not started by VimGDB, the VimGDB specific code
                      > does very little and I do not think it is involved. To make
                      > sure, let's try to prevent ALL VimGDB code from being run:
                      >
                      > a) Do not create the gdb_T structure:
                      > In main.c, comment gdb_new() by replacing:
                      >
                      > #ifdef FEAT_GDB
                      > gdb = gdb_new();
                      > #endif
                      >
                      > with
                      >
                      > #ifdef FEAT_GDB
                      > /* gdb = gdb_new(); */
                      > #endif
                      >
                      > The 'gdb' pointer is NULL for the whole Vim session.
                      > No VimGDB function can run without reading this structure.
                      > No VimGDB specific code can be run from Vim code.

                      No change !!

                      > b) Do not instantiate VimGDB options
                      > If VimGDB still crashes after previous step.
                      > In option.c, at the top of the file, undefine FEAT_GDB, just
                      > below the vim.h inclusion:
                      >
                      > #define IN_OPTION_C
                      > #include "vim.h"
                      >
                      > #undef FEAT_GDB
                      >
                      > VimGDB options are removed.

                      No change !!

                      > c) No VimGDB code in buffer.c
                      > If VimGDB still crashes after previous step.
                      > Same as previous step in buffer.c:
                      >
                      > #include "vim.h"
                      > #undef FEAT_GDB
                      >
                      > The VimGDB code that is removed here, mostly does the same
                      > thing that NetBeans does.

                      No change !!

                      > d) No VimGDB code in ex_getln.c
                      > If VimGDB still crashes after previous step.
                      > Same as previous step in ex_getln.c:
                      >
                      > #include "vim.h"
                      > #undef FEAT_GDB
                      >
                      > After this step, all the code that has been changed in Vim62
                      > by VimGDB are VimGDB functions calling VimGDB code with
                      > a NULL gdb pointer.

                      No change !!


                      > 3 - VimGDB is compiled with a configure file built with
                      > 'make autoconf'
                      >
                      > If VimGDB still crashes after previous step.
                      > To eliminate the cause of the crash as a bad configure file
                      > built by 'make autoconf' during the installation of VimGDB,
                      > let's use the original configure file from Vim62 distribution.
                      >
                      > You have to start from scratch with a Vim62 source tar ball
                      > and the VimGDB patch 6:
                      >
                      > . apply VimGDB patch to a stock Vim62 source code
                      > . do *NOT* run 'make autoconf'
                      > . run 'make' and interrupt it after one or two source
                      > files are compiled
                      > . apply the changes to auto/config.h and auto/config.mk
                      > described below
                      > . run 'make' again to completion and test for crash
                      >
                      > Add to end of auto/config.h:
                      > #define FEAT_GDB 1
                      >
                      > Add to end of auto/config.mk:
                      > GDB_SRC = gdb.c gdb_lvl2.c gdb_lvl3.c pty.c
                      > GDB_OBJ = objects/gdb.o objects/gdb_lvl2.o objects/gdb_lvl3.o objects/pty.o
                      >
                      > Important notes:
                      > I have tested that compilation here with VimGDB patch 6 and
                      > no GUI (faster).
                      > If you compile with the GUI (the default), do not include
                      > 'pty.c' and 'objects/pty.o' in GDB_SRC and GDB_OBJ as these
                      > are already included in the GUI.
                      > If you compile with VimGDB patch 5: do not include all gdb_lvl*

                      I try this later, I'm quite busy at the moment.



                      I tried to find the exact point of crash. I started gbdvim, attached gdb to
                      the running process, set a breakpoint at 'fileio.c:1017', continued and then
                      opened a file in gdbvim and from this place stepped through the code until
                      it crashed.

                      Here is the result:

                      The crash occurs in 'do_one_cmd' called from 'ex_docmd.c:869' at a later
                      iteration (approx > 100) of the do-loop (line 710).
                      Here a stack trace of the call in the first iteration:


                      #0 do_one_cmd (cmdlinep=0x7b042eb4, sourcing=1, cstack=0x7b042ec8, getline=0x400205ba <SD$objects#version+4178>,
                      cookie=0x7b042e10 "@\027\020x") at ex_docmd.c:1311
                      #1 0x00053868 in do_cmdline (cmdline=0x0, getline=0x400205ba <SD$objects#version+4178>, cookie=0x7b042e10 "@\027\020x",
                      flags=7) at ex_docmd.c:869
                      #2 0x00079754 in apply_autocmds_group (event=EVENT_SYNTAX, fname=0x401ae710 "c",
                      fname_io=0x40037050 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c", force=1, group=-3, buf=0x4002b8b0,
                      eap=0x0) at fileio.c:7451
                      #3 0x000790c8 in apply_autocmds (event=EVENT_SYNTAX, fname=0x4002b890 "c",
                      fname_io=0x40037050 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c", force=1, buf=0x4002b8b0)
                      at fileio.c:7141
                      #4 0x000e37c4 in did_set_string_option (opt_idx=254, varp=0x4002c010, new_value_alloced=1, oldval=0x40037288 "",
                      errbuf=0x7b042bf8 "\030}\214{\004\a{\004\b", opt_flags=0) at option.c:5265
                      #5 0x000e0ef0 in do_set (arg=0x401a4fcc "", opt_flags=0) at option.c:3905
                      #6 0x00063bd4 in ex_set (eap=0x7b042aa0) at ex_docmd.c:9091
                      #7 0x000561a4 in $0000011A () at ex_docmd.c:2183
                      #8 0x00053868 in do_cmdline (cmdline=0x401ae6b8 "set syntax=c", getline=0x400205ba <SD$objects#version+4178>,
                      cookie=0x7b042290 "@\003q\220", flags=3) at ex_docmd.c:869
                      #9 0x0003a3e4 in ex_execute (eap=0x7b042620) at eval.c:8361
                      #10 0x000561a4 in $0000011A () at ex_docmd.c:2183
                      #11 0x00053868 in do_cmdline (cmdline=0x0, getline=0x400205ba <SD$objects#version+4178>, cookie=0x7b042290 "@\003q\220",
                      flags=7) at ex_docmd.c:869
                      #12 0x00079754 in apply_autocmds_group (event=EVENT_FILETYPE, fname=0x40171c08 "c",
                      fname_io=0x40037050 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c", force=1, group=-3, buf=0x4002b8b0,
                      eap=0x0) at fileio.c:7451
                      #13 0x000790c8 in apply_autocmds (event=EVENT_FILETYPE, fname=0x40074b48 "c",
                      fname_io=0x40037050 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c", force=1, buf=0x4002b8b0)
                      at fileio.c:7141
                      #14 0x000e3820 in did_set_string_option (opt_idx=80, varp=0x4002bfa8, new_value_alloced=1, oldval=0x4002c8b0 "", errbuf=0x0,
                      opt_flags=4) at option.c:5274
                      #15 0x000e225c in set_string_option (opt_idx=80, value=0x4003729f "c", opt_flags=4) at option.c:4486
                      #16 0x000e6a20 in set_option_value (name=0x40007c58 "filetype", number=0, string=0x4003729f "c", opt_flags=4) at option.c:6938
                      #17 0x00063b0c in ex_setfiletype (eap=0x7b041fa0) at ex_docmd.c:9057
                      #18 0x000561a4 in $0000011A () at ex_docmd.c:2183
                      #19 0x00053868 in do_cmdline (cmdline=0x0, getline=0x4001fb82 <SD$objects#version+1562>, cookie=0x7b041b7c "@\003", flags=7)
                      at ex_docmd.c:869
                      #20 0x0003c7cc in call_user_func (fp=0x4003e800, argcount=0, argvars=0x7b041930, retvar=0x7b041890, firstline=1, lastline=1)
                      at eval.c:9164
                      #21 0x00031c4c in call_func (name=0x40037265 "<SID>FTlpc", len=10, retvar=0x7b041890, argcount=0, argvars=0x7b041930,
                      firstline=1, lastline=1, doesrange=0x7b0418a4, evaluate=1) at eval.c:3108
                      #22 0x00031814 in get_func_var (name=0x40037265 "<SID>FTlpc", len=10, retvar=0x7b041890, arg=0x7b041880, firstline=1,
                      lastline=1, doesrange=0x7b0418a4, evaluate=1) at eval.c:2967
                      #23 0x0002e9e0 in ex_call (eap=0x7b0417a0) at eval.c:1298
                      #24 0x000561a4 in $0000011A () at ex_docmd.c:2183
                      #25 0x00053868 in do_cmdline (cmdline=0x0, getline=0x400205ba <SD$objects#version+4178>, cookie=0x7b041410 "@\003", flags=7)
                      at ex_docmd.c:869
                      #26 0x00079754 in apply_autocmds_group (event=EVENT_BUFREADPOST,
                      fname=0x40178238 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c",
                      fname_io=0x40037050 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c", force=0, group=-3, buf=0x4002b8b0,
                      eap=0x7b040f20) at fileio.c:7451
                      #27 0x00079124 in apply_autocmds_exarg (event=EVENT_BUFREADPOST, fname=0x0,
                      fname_io=0x40037050 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c", force=0, buf=0x4002b8b0,
                      eap=0x7b040f20) at fileio.c:7158
                      #28 0x00072768 in readfile (fname=0x40037050 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c",
                      sfname=0x40037050 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c", from=0, lines_to_skip=0,
                      lines_to_read=2147483647, eap=0x7b040f20, flags=1) at fileio.c:2080
                      #29 0x0000e9a8 in __SB_masks () from ./vim
                      #30 0x00043374 in do_ecmd (fnum=0, ffname=0x40032730 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c",
                      sfname=0x40036f8a "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c", eap=0x7b040f20, newlnum=0, flags=0)
                      at ex_cmds.c:2974
                      #31 0x0005e540 in do_exedit (eap=0x7b040f20, old_curwin=0x0) at ex_docmd.c:6196
                      #32 0x0005e2e8 in ex_edit (eap=0x7b040f20) at ex_docmd.c:6139
                      #33 0x000561a4 in $0000011A () at ex_docmd.c:2183
                      #34 0x00053868 in do_cmdline (cmdline=0x0, getline=0x4001ff4a <SD$objects#version+2530>, cookie=0x0, flags=0)
                      at ex_docmd.c:869
                      #35 0x000ca22c in nv_colon (cap=0x7b040b08) at normal.c:4576
                      #36 0x000c35b0 in normal_cmd (oap=0x7b040a70, toplevel=1) at normal.c:1084
                      #37 0x000922f8 in main_loop (cmdwin=0) at main.c:2131
                      #38 0x00091ea8 in $00000072 () at main.c:1949


                      I hope this information is in some way useful to you.

                      Malte


                      --
                      --------------------------------------------------------------------------
                      Malte Neumann
                      --------------------------------------------------------------------------
                      Institut fuer Baustatik / Institute of Structural Mechanics
                      Prof. Dr.-Ing. Ekkehard Ramm
                      Universitaet Stuttgart / University of Stuttgart

                      Pfaffenwaldring 7, D-70550 Stuttgart, Germany

                      mailto:neumann@...-stuttgart.de phone: ++49-711-685-6121
                      http://www.uni-stuttgart.de/ibs/members/neumann/ fax: ++49-711-685-6130
                      --------------------------------------------------------------------------
                    • Xavier de Gaye
                      ... To be quite thorough, file os_unix.c must be taken care off too (assuming you are running VimGDB in a terminal, not gvim). To do that, you can replace
                      Message 10 of 19 , Apr 19, 2004
                      • 0 Attachment
                        On 4/15/2004, Malte Neumann wrote:

                        > [...]
                        > > d) No VimGDB code in ex_getln.c
                        > > If VimGDB still crashes after previous step.
                        > > Same as previous step in ex_getln.c:
                        > >
                        > > #include "vim.h"
                        > > #undef FEAT_GDB
                        > >
                        > > After this step, all the code that has been changed in Vim62
                        > > by VimGDB are VimGDB functions calling VimGDB code with
                        > > a NULL gdb pointer.
                        >
                        > No change !!
                        >

                        To be quite thorough, file os_unix.c must be taken care off
                        too (assuming you are running VimGDB in a terminal, not
                        gvim). To do that, you can replace os_unix.c with the
                        original one from Vim62 and run the crash test. I don't
                        think it is absolutely necessary. After the above tests, I
                        am quite sure VimGDB code is not involved.

                        The problem must lie somewhere in the way VimGDB is built or
                        is run.

                        > [...]
                        > I tried to find the exact point of crash. I started gbdvim, attached gdb to
                        > the running process, set a breakpoint at 'fileio.c:1017', continued and then
                        > opened a file in gdbvim and from this place stepped through the code until
                        > it crashed.
                        >
                        > Here is the result:
                        >
                        > The crash occurs in 'do_one_cmd' called from 'ex_docmd.c:869' at a later
                        > iteration (approx > 100) of the do-loop (line 710).
                        > Here a stack trace of the call in the first iteration:
                        >
                        >
                        > #0 do_one_cmd (cmdlinep=0x7b042eb4, sourcing=1, cstack=0x7b042ec8, getline=0x400205ba <SD$objects#version+4178>,
                        > cookie=0x7b042e10 "@\027\020x") at ex_docmd.c:1311
                        > #1 0x00053868 in do_cmdline (cmdline=0x0, getline=0x400205ba <SD$objects#version+4178>, cookie=0x7b042e10 "@\027\020x",
                        > flags=7) at ex_docmd.c:869
                        > #2 0x00079754 in apply_autocmds_group (event=EVENT_SYNTAX, fname=0x401ae710 "c", fname_io=0x40037050 "/users/statik/neumann/wdir/ccarat_repos/src/main/main_ccarat.c", force=1, group=-3, buf=0x4002b8b0,
                        > eap=0x0) at fileio.c:7451
                        > [...]
                        > #38 0x00091ea8 in $00000072 () at main.c:1949
                        >
                        >
                        > I hope this information is in some way useful to you.
                        >
                        > Malte

                        Very interesting. Remember, it crashes too in 'make test'
                        with 'test11.in', and this test is about autocommands. So we
                        are focusing on syntax files, when the problem is
                        actually autocommands (syntax files are read through
                        autocommands).

                        It would be interesting to try this and see if that crashes:

                        start VimGDB
                        type few lines in this empty buffer
                        type the Vim commands:
                        :au FileWritePre *.gz 1,$!gzip
                        :au FileWritePost *.gz undo
                        :1,$write! foobar.gz

                        It is meant to gzip/write the buffer content to file
                        foobar.gz.

                        Then if it crashes (and it should since it's a very slight
                        adaptation from 'test11.in'), then we have a very simple
                        test case. Getting closer to having the beast cornered.

                        Do you have autocommands in your .vimrc ?

                        From the backtrace above, you are using macro expansions and
                        probably compiling with -g3. Make sure that you do the same
                        for Vim62 when comparing crash tests between VimGDB and
                        Vim62: the tests must be strictly identical since we are
                        looking for what causes one to crash and not the other.

                        Are you using the same VIM runtime environment in both cases ?

                        Xavier...



                        __________________________________________________________________
                        Introducing the New Netscape Internet Service.
                        Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

                        Netscape. Just the Net You Need.

                        New! Netscape Toolbar for Internet Explorer
                        Search from anywhere on the Web and block those annoying pop-ups.
                        Download now at http://channels.netscape.com/ns/search/install.jsp
                      • Malte Neumann
                        ... [...] ... [...] ... You can see the results in the attached files. ... Yes, to create some filetype specific mappings and for special settings for large
                        Message 11 of 19 , Apr 19, 2004
                        • 0 Attachment
                          On Mon, Apr 19, 2004 at 05:35:56AM -0400, Xavier de Gaye wrote:
                          >
                          > On 4/15/2004, Malte Neumann wrote:

                          [...]

                          > To be quite thorough, file os_unix.c must be taken care off
                          > too (assuming you are running VimGDB in a terminal, not
                          > gvim). To do that, you can replace os_unix.c with the
                          > original one from Vim62 and run the crash test. I don't
                          > think it is absolutely necessary. After the above tests, I
                          > am quite sure VimGDB code is not involved.
                          >
                          > The problem must lie somewhere in the way VimGDB is built or
                          > is run.

                          [...]

                          > Very interesting. Remember, it crashes too in 'make test'
                          > with 'test11.in', and this test is about autocommands. So we
                          > are focusing on syntax files, when the problem is
                          > actually autocommands (syntax files are read through
                          > autocommands).
                          >
                          > It would be interesting to try this and see if that crashes:
                          >
                          > start VimGDB
                          > type few lines in this empty buffer
                          > type the Vim commands:
                          > :au FileWritePre *.gz 1,$!gzip
                          > :au FileWritePost *.gz undo
                          > :1,$write! foobar.gz
                          >
                          > It is meant to gzip/write the buffer content to file
                          > foobar.gz.
                          >
                          > Then if it crashes (and it should since it's a very slight
                          > adaptation from 'test11.in'), then we have a very simple
                          > test case. Getting closer to having the beast cornered.

                          You can see the results in the attached files.

                          > Do you have autocommands in your .vimrc ?

                          Yes, to create some filetype specific mappings and for special settings for
                          large files.

                          > From the backtrace above, you are using macro expansions and
                          > probably compiling with -g3. Make sure that you do the same
                          > for Vim62 when comparing crash tests between VimGDB and
                          > Vim62: the tests must be strictly identical since we are
                          > looking for what causes one to crash and not the other.
                          >
                          > Are you using the same VIM runtime environment in both cases ?

                          I recompiled the stock Vim 6.2 without any configuration and started with
                          VimGDB 6 from scratch, not using autoconf, but following the instructions
                          from your last mail. I summarized the results including a ':version' in two
                          files (best viewed side-by-side with a vsplit or even diff) attached to this
                          mail (sorry for the attachment).


                          But, these results might become irrelevant as I found the line that is
                          causing the trouble. It's in the file os_unix.c as you suggested above.
                          Deleting the lines 1117-1119:

                          #if defined(FEAT_GDB) && defined(SIGCHLD)
                          signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                          #endif

                          from this file makes VimGDB behave as expected
                          (as far as I have tested).
                          - opening a file is no problem
                          - make test gives the following result:
                          Test results:
                          test18 FAILED
                          test32 FAILED
                          ALL DONE
                          - your little test from above also works

                          I so far did not experience any loss in functionality because of this
                          missing line, but did not do any real debugging.

                          Regards

                          Malte


                          --
                          --------------------------------------------------------------------------
                          Malte Neumann
                          --------------------------------------------------------------------------
                          Institut fuer Baustatik / Institute of Structural Mechanics
                          Prof. Dr.-Ing. Ekkehard Ramm
                          Universitaet Stuttgart / University of Stuttgart

                          Pfaffenwaldring 7, D-70550 Stuttgart, Germany

                          mailto:neumann@...-stuttgart.de phone: ++49-711-685-6121
                          http://www.uni-stuttgart.de/ibs/members/neumann/ fax: ++49-711-685-6130
                          --------------------------------------------------------------------------
                        • Xavier de Gaye
                          ... I am so happy you found it. Thanks a lot. This was a tough one ! The crash test with autocommands and gzip is explained because gzip is forked and sends a
                          Message 12 of 19 , Apr 23, 2004
                          • 0 Attachment
                            On 4/19/2004 Malte Neumann wrote:

                            > On Mon, Apr 19, 2004 at 05:35:56AM -0400, Xavier de Gaye wrote:
                            >
                            > [...]
                            >
                            > But, these results might become irrelevant as I found the line that is
                            > causing the trouble. It's in the file os_unix.c as you suggested above.
                            > Deleting the lines 1117-1119:
                            >
                            > #if defined(FEAT_GDB) && defined(SIGCHLD)
                            > signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                            > #endif
                            >

                            I am so happy you found it. Thanks a lot. This was a tough one !

                            The crash test with autocommands and gzip is explained because
                            gzip is forked and sends a SIGCHLD. Does running the Vim command
                            ":!ls" makes VimGDB crash too ?

                            This does not explain why it crashes when loading the syntax, but
                            maybe some process is forked with your setup.

                            I can't see what is wrong with gdb_catch_sigchld(), maybe the
                            signal handlers don't have arguments with the library you are
                            using on your system ?
                            Can you check that in the library documentation ?
                            It would be nice to understand what's wrong.


                            > from this file makes VimGDB behave as expected
                            > (as far as I have tested).
                            > - opening a file is no problem
                            > - make test gives the following result:
                            > Test results:
                            > test18 FAILED
                            > test32 FAILED
                            > ALL DONE
                            > - your little test from above also works
                            >
                            > I so far did not experience any loss in functionality because of this
                            > missing line, but did not do any real debugging.
                            >
                            > Regards
                            >
                            > Malte

                            The only functionality you lose is the ability to run multiple GDB
                            successive sessions within the same Vim session: to stop GDB without
                            handling SIGCHLD, you must quit Vim, you cannot use the GDB "quit"
                            command.

                            To fix that, try making those changes in os_unix.c and gdb.c:

                            ...........................................................
                            In os_unix.c, restore lines 1117-1119 in set_signals():

                            #if defined(FEAT_GDB) && defined(SIGCHLD)
                            signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                            #endif

                            ...........................................................
                            In os_unix.c replace fuction gdb_catch_sigchld() with:

                            #if defined(FEAT_GDB) && defined(SIGCHLD)
                            /*
                            * On SIGCHLD, note when gdb process is defunct or does not exist any more
                            */
                            static RETSIGTYPE
                            gdb_catch_sigchld SIGDEFARG(sigarg)
                            {
                            if (gdb_pid(gdb) != -1)
                            gdb_set_sigchld(gdb, TRUE);

                            signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                            SIGRETURN;
                            }
                            #endif

                            ...........................................................
                            In gdb.c replace gdb_sigchld() with:

                            /** Return TRUE when there is a pending SIGCHLD */
                            int
                            gdb_sigchld(gdb)
                            gdb_handle_T *gdb;
                            {
                            if (GDB_STATE(gdb, GS_SIGCHLD))
                            {
                            pid_t wait_pid;
                            pid_t pid;

                            gdb_set_sigchld(gdb, FALSE);

                            if ((pid = gdb_pid(gdb)) != -1)
                            {
                            wait_pid = waitpid(pid, NULL, WNOHANG);

                            if ((wait_pid == (pid_t)-1 && errno == ECHILD)
                            || wait_pid == pid)
                            gdb_set_sigchld(gdb, TRUE);
                            }
                            }
                            return GDB_STATE(gdb, GS_SIGCHLD);
                            }
                            ...........................................................



                            If this does not work, then we have to use a global variable.
                            Try making those changes in global.h, os_unix.c and gdb.c:

                            ...........................................................
                            In global.h, at lines 1020, add one line to define
                            gdb_got_sigchld:

                            #ifdef FEAT_GDB
                            EXTERN gdb_handle_T *gdb INIT(= NULL); /* gdb opaque handle */
                            EXTERN int gdb_got_sigchld INIT(= FALSE);
                            #endif

                            ...........................................................
                            In os_unix.c, restore lines 1117-1119 in set_signals():

                            #if defined(FEAT_GDB) && defined(SIGCHLD)
                            signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                            #endif

                            ...........................................................
                            In os_unix.c replace fuction gdb_catch_sigchld() with:

                            #if defined(FEAT_GDB) && defined(SIGCHLD)
                            /*
                            * On SIGCHLD, note when gdb process is defunct or does not exist any more
                            */
                            static RETSIGTYPE
                            gdb_catch_sigchld SIGDEFARG(sigarg)
                            {
                            gdb_got_sigchld = TRUE;

                            signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                            SIGRETURN;
                            }
                            #endif

                            ...........................................................
                            In gdb.c replace gdb_sigchld() with:

                            /** Return TRUE when there is a pending SIGCHLD */
                            int
                            gdb_sigchld(gdb)
                            gdb_handle_T *gdb;
                            {
                            gdb_set_sigchld(gdb, FALSE);

                            if (gdb_got_sigchld)
                            {
                            pid_t wait_pid;
                            pid_t pid;

                            gdb_got_sigchld = FALSE;

                            if ((pid = gdb_pid(gdb)) != -1)
                            {
                            wait_pid = waitpid(pid, NULL, WNOHANG);

                            if ((wait_pid == (pid_t)-1 && errno == ECHILD)
                            || wait_pid == pid)
                            gdb_set_sigchld(gdb, TRUE);
                            }
                            }
                            return GDB_STATE(gdb, GS_SIGCHLD);
                            }

                            ...........................................................

                            Thanks for your help.

                            Xavier...



                            __________________________________________________________________
                            Introducing the New Netscape Internet Service.
                            Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

                            Netscape. Just the Net You Need.

                            New! Netscape Toolbar for Internet Explorer
                            Search from anywhere on the Web and block those annoying pop-ups.
                            Download now at http://channels.netscape.com/ns/search/install.jsp
                          • Malte Neumann
                            ... Yes. ... Where do I find the documentation? This is part of man signal : SYNOPSIS #include void (*signal(int sig, void (*func)(int)))(int);
                            Message 13 of 19 , May 1, 2004
                            • 0 Attachment
                              On Fri, Apr 23, 2004 at 08:38:48AM -0400, Xavier de Gaye wrote:
                              >
                              > On 4/19/2004 Malte Neumann wrote:
                              >
                              > > On Mon, Apr 19, 2004 at 05:35:56AM -0400, Xavier de Gaye wrote:
                              > >
                              > > [...]
                              > >
                              > > But, these results might become irrelevant as I found the line that is
                              > > causing the trouble. It's in the file os_unix.c as you suggested above.
                              > > Deleting the lines 1117-1119:
                              > >
                              > > #if defined(FEAT_GDB) && defined(SIGCHLD)
                              > > signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                              > > #endif
                              > >
                              >
                              > I am so happy you found it. Thanks a lot. This was a tough one !
                              >
                              > The crash test with autocommands and gzip is explained because
                              > gzip is forked and sends a SIGCHLD. Does running the Vim command
                              > ":!ls" makes VimGDB crash too ?

                              Yes.

                              > This does not explain why it crashes when loading the syntax, but
                              > maybe some process is forked with your setup.
                              >
                              > I can't see what is wrong with gdb_catch_sigchld(), maybe the
                              > signal handlers don't have arguments with the library you are
                              > using on your system ?
                              > Can you check that in the library documentation ?
                              > It would be nice to understand what's wrong.

                              Where do I find the documentation?
                              This is part of 'man signal':

                              SYNOPSIS
                              #include <signal.h>

                              void (*signal(int sig, void (*func)(int)))(int);

                              Maybe that's what you are looking for. I also found the 'signal.h', if
                              this might be better.


                              > > from this file makes VimGDB behave as expected
                              > > (as far as I have tested).
                              > > - opening a file is no problem
                              > > - make test gives the following result:
                              > > Test results:
                              > > test18 FAILED
                              > > test32 FAILED
                              > > ALL DONE
                              > > - your little test from above also works
                              > >
                              > > I so far did not experience any loss in functionality because of this
                              > > missing line, but did not do any real debugging.
                              > >
                              > > Regards
                              > >
                              > > Malte
                              >
                              > The only functionality you lose is the ability to run multiple GDB
                              > successive sessions within the same Vim session: to stop GDB without
                              > handling SIGCHLD, you must quit Vim, you cannot use the GDB "quit"
                              > command.
                              >
                              > To fix that, try making those changes in os_unix.c and gdb.c:
                              >
                              > ...........................................................
                              > In os_unix.c, restore lines 1117-1119 in set_signals():
                              >
                              > #if defined(FEAT_GDB) && defined(SIGCHLD)
                              > signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                              > #endif
                              >
                              > ...........................................................
                              > In os_unix.c replace fuction gdb_catch_sigchld() with:
                              >
                              > #if defined(FEAT_GDB) && defined(SIGCHLD)
                              > /*
                              > * On SIGCHLD, note when gdb process is defunct or does not exist any more
                              > */
                              > static RETSIGTYPE
                              > gdb_catch_sigchld SIGDEFARG(sigarg)
                              > {
                              > if (gdb_pid(gdb) != -1)
                              > gdb_set_sigchld(gdb, TRUE);
                              >
                              > signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                              > SIGRETURN;
                              > }
                              > #endif
                              >
                              > ...........................................................
                              > In gdb.c replace gdb_sigchld() with:
                              >
                              > /** Return TRUE when there is a pending SIGCHLD */
                              > int
                              > gdb_sigchld(gdb)
                              > gdb_handle_T *gdb;
                              > {
                              > if (GDB_STATE(gdb, GS_SIGCHLD))
                              > {
                              > pid_t wait_pid;
                              > pid_t pid;
                              >
                              > gdb_set_sigchld(gdb, FALSE);
                              >
                              > if ((pid = gdb_pid(gdb)) != -1)
                              > {
                              > wait_pid = waitpid(pid, NULL, WNOHANG);
                              >
                              > if ((wait_pid == (pid_t)-1 && errno == ECHILD)
                              > || wait_pid == pid)
                              > gdb_set_sigchld(gdb, TRUE);
                              > }
                              > }
                              > return GDB_STATE(gdb, GS_SIGCHLD);
                              > }
                              > ...........................................................
                              >
                              >
                              >
                              > If this does not work, then we have to use a global variable.
                              > Try making those changes in global.h, os_unix.c and gdb.c:
                              >
                              > ...........................................................
                              > In global.h, at lines 1020, add one line to define
                              > gdb_got_sigchld:
                              >
                              > #ifdef FEAT_GDB
                              > EXTERN gdb_handle_T *gdb INIT(= NULL); /* gdb opaque handle */
                              > EXTERN int gdb_got_sigchld INIT(= FALSE);
                              > #endif
                              >
                              > ...........................................................
                              > In os_unix.c, restore lines 1117-1119 in set_signals():
                              >
                              > #if defined(FEAT_GDB) && defined(SIGCHLD)
                              > signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                              > #endif
                              >
                              > ...........................................................
                              > In os_unix.c replace fuction gdb_catch_sigchld() with:
                              >
                              > #if defined(FEAT_GDB) && defined(SIGCHLD)
                              > /*
                              > * On SIGCHLD, note when gdb process is defunct or does not exist any more
                              > */
                              > static RETSIGTYPE
                              > gdb_catch_sigchld SIGDEFARG(sigarg)
                              > {
                              > gdb_got_sigchld = TRUE;
                              >
                              > signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                              > SIGRETURN;
                              > }
                              > #endif
                              >
                              > ...........................................................
                              > In gdb.c replace gdb_sigchld() with:
                              >
                              > /** Return TRUE when there is a pending SIGCHLD */
                              > int
                              > gdb_sigchld(gdb)
                              > gdb_handle_T *gdb;
                              > {
                              > gdb_set_sigchld(gdb, FALSE);
                              >
                              > if (gdb_got_sigchld)
                              > {
                              > pid_t wait_pid;
                              > pid_t pid;
                              >
                              > gdb_got_sigchld = FALSE;
                              >
                              > if ((pid = gdb_pid(gdb)) != -1)
                              > {
                              > wait_pid = waitpid(pid, NULL, WNOHANG);
                              >
                              > if ((wait_pid == (pid_t)-1 && errno == ECHILD)
                              > || wait_pid == pid)
                              > gdb_set_sigchld(gdb, TRUE);
                              > }
                              > }
                              > return GDB_STATE(gdb, GS_SIGCHLD);
                              > }
                              >
                              > ...........................................................

                              Both variants did not change the behaviour at all. VimGDB still crashes when
                              opening a file.



                              Just one other question:
                              On this HP system we talking about all the time, the <TAB> completion in the
                              gdb window input-line does not work. Does it depend on a special version of
                              gdb?

                              Thanks for the help.

                              Malte

                              --
                              --------------------------------------------------------------------------
                              Malte Neumann
                              --------------------------------------------------------------------------
                              Institut fuer Baustatik / Institute of Structural Mechanics
                              Prof. Dr.-Ing. Ekkehard Ramm
                              Universitaet Stuttgart / University of Stuttgart

                              Pfaffenwaldring 7, D-70550 Stuttgart, Germany

                              mailto:neumann@...-stuttgart.de phone: ++49-711-685-6121
                              http://www.uni-stuttgart.de/ibs/members/neumann/ fax: ++49-711-685-6130
                              --------------------------------------------------------------------------
                            • Xavier de Gaye
                              ... From that prototype, signal handlers take an int as argument. ... The function gdb_sigchld(), in this last variant, is never called as GDB is not started.
                              Message 14 of 19 , May 7, 2004
                              • 0 Attachment
                                On 5/1/2004 Malte Neumann wrote:
                                > [...]
                                > > I can't see what is wrong with gdb_catch_sigchld(), maybe the
                                > > signal handlers don't have arguments with the library you are
                                > > using on your system ?
                                > > Can you check that in the library documentation ?
                                > > It would be nice to understand what's wrong.
                                >
                                > Where do I find the documentation?
                                > This is part of 'man signal':
                                >
                                > SYNOPSIS
                                > #include <signal.h>
                                >
                                > void (*signal(int sig, void (*func)(int)))(int);

                                From that prototype, signal handlers take an int as argument.



                                > [...]
                                > > If this does not work, then we have to use a global variable.
                                > > Try making those changes in global.h, os_unix.c and gdb.c:
                                > >
                                > > ...........................................................
                                > > In global.h, at lines 1020, add one line to define
                                > > gdb_got_sigchld:
                                > >
                                > > #ifdef FEAT_GDB
                                > > EXTERN gdb_handle_T *gdb INIT(= NULL); /* gdb opaque handle */
                                > > EXTERN int gdb_got_sigchld INIT(= FALSE);
                                > > #endif
                                > >
                                > > ...........................................................
                                > > In os_unix.c, restore lines 1117-1119 in set_signals():
                                > >
                                > > #if defined(FEAT_GDB) && defined(SIGCHLD)
                                > > signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                                > > #endif
                                > >
                                > > ...........................................................
                                > > In os_unix.c replace fuction gdb_catch_sigchld() with:
                                > >
                                > > #if defined(FEAT_GDB) && defined(SIGCHLD)
                                > > /*
                                > > * On SIGCHLD, note when gdb process is defunct or does not exist any more
                                > > */
                                > > static RETSIGTYPE
                                > > gdb_catch_sigchld SIGDEFARG(sigarg)
                                > > {
                                > > gdb_got_sigchld = TRUE;
                                > >
                                > > signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                                > > SIGRETURN;
                                > > }
                                > > #endif
                                > >
                                > > ...........................................................
                                > > In gdb.c replace gdb_sigchld() with:
                                > >
                                > > /** Return TRUE when there is a pending SIGCHLD */
                                > > int
                                > > gdb_sigchld(gdb)
                                > > gdb_handle_T *gdb;
                                > > {
                                > > gdb_set_sigchld(gdb, FALSE);
                                > >
                                > > if (gdb_got_sigchld)
                                > > {
                                > > pid_t wait_pid;
                                > > pid_t pid;
                                > >
                                > > gdb_got_sigchld = FALSE;
                                > >
                                > > if ((pid = gdb_pid(gdb)) != -1)
                                > > {
                                > > wait_pid = waitpid(pid, NULL, WNOHANG);
                                > >
                                > > if ((wait_pid == (pid_t)-1 && errno == ECHILD)
                                > > || wait_pid == pid)
                                > > gdb_set_sigchld(gdb, TRUE);
                                > > }
                                > > }
                                > > return GDB_STATE(gdb, GS_SIGCHLD);
                                > > }
                                > >
                                > > ...........................................................
                                >
                                > Both variants did not change the behaviour at all. VimGDB still crashes when
                                > opening a file.
                                >
                                >

                                The function gdb_sigchld(), in this last variant, is never called as GDB
                                is not started. The bug is therefore in these few lines and their macros:

                                static RETSIGTYPE
                                gdb_catch_sigchld SIGDEFARG(sigarg)
                                {
                                gdb_got_sigchld = TRUE;

                                signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                                SIGRETURN;
                                }



                                Please try replacing gdb_catch_sigchld() with the following and check if
                                it crashes:

                                static void
                                gdb_catch_sigchld (sigarg) int sigarg;
                                {
                                gdb_got_sigchld = 1;

                                signal(SIGCHLD, gdb_catch_sigchld);
                                }



                                Also, could you preprocces os_unix.c and see how these macros
                                are expanded. To do that, simply run:

                                gcc -I. -Iproto -DHAVE_CONFIG_H -E os_unix.c >os_unix.i


                                What I get here on Linux in the resulting file 'os_unix.i' is:
                                (line numbers won't probably match with yours)

                                # 159 "os_unix.c"
                                static void gdb_catch_sigchld (int);

                                # 828 "os_unix.c"
                                static void
                                gdb_catch_sigchld (sigarg) int sigarg;
                                {
                                # 850 "os_unix.c"
                                gdb_got_sigchld = 1;

                                sigset(17, (void (*)())gdb_catch_sigchld);
                                return;
                                }

                                What have you got on your side in 'os_unix.i' with gdb_catch_sigchld() ?



                                > Just one other question:
                                > On this HP system we talking about all the time, the <TAB> completion in the
                                > gdb window input-line does not work. Does it depend on a special version of gdb?

                                No it does not. Assuming that the GDB you are using can be used with
                                completion, as a check, try this on Vim command line:

                                :call gdb("show ann^I")

                                (in order to insert the '^I' character in this quoted string, you must
                                type the two following characters: <CTRL-V><CTRL-I> - do not type <TAB>)

                                As a result the input-line window must pop up and display the completion
                                result: 'show annotate'.


                                Xavier...



                                __________________________________________________________________
                                Introducing the New Netscape Internet Service.
                                Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

                                Netscape. Just the Net You Need.

                                New! Netscape Toolbar for Internet Explorer
                                Search from anywhere on the Web and block those annoying pop-ups.
                                Download now at http://channels.netscape.com/ns/search/install.jsp
                              • Malte Neumann
                                ... [...] ... VimGDB still crashes. ... I get the following THREE occurences of gdb_catch_sigchld static void gdb_catch_sigchld (int); # 888 os_unix.c
                                Message 15 of 19 , May 10, 2004
                                • 0 Attachment
                                  On Fri, May 07, 2004 at 09:18:09AM -0400, Xavier de Gaye wrote:
                                  >
                                  > On 5/1/2004 Malte Neumann wrote:
                                  > > [...]
                                  > > > I can't see what is wrong with gdb_catch_sigchld(), maybe the
                                  > > > signal handlers don't have arguments with the library you are
                                  > > > using on your system ?
                                  > > > Can you check that in the library documentation ?
                                  > > > It would be nice to understand what's wrong.
                                  > >
                                  > > Where do I find the documentation?
                                  > > This is part of 'man signal':
                                  > >
                                  > > SYNOPSIS
                                  > > #include <signal.h>
                                  > >
                                  > > void (*signal(int sig, void (*func)(int)))(int);
                                  >
                                  > From that prototype, signal handlers take an int as argument.
                                  >
                                  > > [...]
                                  > > > If this does not work, then we have to use a global variable.
                                  > > > Try making those changes in global.h, os_unix.c and gdb.c:

                                  [...]

                                  > > Both variants did not change the behaviour at all. VimGDB still crashes
                                  > > when opening a file.
                                  > >
                                  >
                                  > The function gdb_sigchld(), in this last variant, is never called as GDB
                                  > is not started. The bug is therefore in these few lines and their macros:
                                  >
                                  > static RETSIGTYPE
                                  > gdb_catch_sigchld SIGDEFARG(sigarg)
                                  > {
                                  > gdb_got_sigchld = TRUE;
                                  >
                                  > signal(SIGCHLD, (RETSIGTYPE (*)())gdb_catch_sigchld);
                                  > SIGRETURN;
                                  > }
                                  >
                                  >
                                  > Please try replacing gdb_catch_sigchld() with the following and check if
                                  > it crashes:
                                  >
                                  > static void
                                  > gdb_catch_sigchld (sigarg) int sigarg;
                                  > {
                                  > gdb_got_sigchld = 1;
                                  >
                                  > signal(SIGCHLD, gdb_catch_sigchld);
                                  > }

                                  VimGDB still crashes.

                                  > Also, could you preprocces os_unix.c and see how these macros
                                  > are expanded. To do that, simply run:
                                  >
                                  > gcc -I. -Iproto -DHAVE_CONFIG_H -E os_unix.c >os_unix.i
                                  >
                                  >
                                  > What I get here on Linux in the resulting file 'os_unix.i' is:
                                  > (line numbers won't probably match with yours)
                                  >
                                  > # 159 "os_unix.c"
                                  > static void gdb_catch_sigchld (int);
                                  >
                                  > # 828 "os_unix.c"
                                  > static void
                                  > gdb_catch_sigchld (sigarg) int sigarg;
                                  > {
                                  > # 850 "os_unix.c"
                                  > gdb_got_sigchld = 1;
                                  >
                                  > sigset(17, (void (*)())gdb_catch_sigchld);
                                  > return;
                                  > }
                                  >
                                  > What have you got on your side in 'os_unix.i' with gdb_catch_sigchld() ?

                                  I get the following THREE occurences of 'gdb_catch_sigchld'


                                  static void gdb_catch_sigchld (int);


                                  # 888 "os_unix.c"
                                  static void
                                  gdb_catch_sigchld (sigarg) int sigarg;
                                  {
                                  gdb_got_sigchld = 1;

                                  sigset(18, gdb_catch_sigchld);
                                  }


                                  # 1192 "os_unix.c"
                                  sigset(18, (void (*)())gdb_catch_sigchld);


                                  The line 1192 was originally one of the lines 1117-1119.

                                  I hope I did not mix up your changes at some place.


                                  > > Just one other question: On this HP system we talking about all the
                                  > > time, the <TAB> completion in the gdb window input-line does not work.
                                  > > Does it depend on a special version of gdb?
                                  >
                                  > No it does not. Assuming that the GDB you are using can be used with
                                  > completion, as a check, try this on Vim command line:
                                  >
                                  > :call gdb("show ann^I")
                                  >
                                  > (in order to insert the '^I' character in this quoted string, you must
                                  > type the two following characters: <CTRL-V><CTRL-I> - do not type <TAB>)
                                  >
                                  > As a result the input-line window must pop up and display the completion
                                  > result: 'show annotate'.

                                  I get as a result no input-line window and trying to issue any other gdb
                                  command (like 'set args' or 'break') I get the answer:

                                  GDB busy: command discarded, please retry

                                  I have to quit VimGDB to finish this state.


                                  Maybe I should mention that I use a mapping for the <TAB> key, but I believe
                                  that on my Linux Box with the same .vimrc the completion works. I have the
                                  following in my .vimrc concerning the <TAB>:

                                  .. .vimrc ........................................
                                  function InsertTabWrapper()
                                  let col = col('.') - 1
                                  if !col || getline('.')[col - 1] !~ '\k'
                                  return "\<tab>"
                                  else
                                  return "\<c-p>"
                                  endif
                                  endfunction

                                  inoremap <tab> <c-r>=InsertTabWrapper()<cr>
                                  ..................................................


                                  Thanks for yout help

                                  Malte

                                  --
                                  --------------------------------------------------------------------------
                                  Malte Neumann
                                  --------------------------------------------------------------------------
                                  Institut fuer Baustatik / Institute of Structural Mechanics
                                  Prof. Dr.-Ing. Ekkehard Ramm
                                  Universitaet Stuttgart / University of Stuttgart

                                  Pfaffenwaldring 7, D-70550 Stuttgart, Germany

                                  mailto:neumann@...-stuttgart.de phone: ++49-711-685-6121
                                  http://www.uni-stuttgart.de/ibs/members/neumann/ fax: ++49-711-685-6130
                                  --------------------------------------------------------------------------
                                • Xavier de Gaye
                                  ... No, actually it s me and my own changes, sorry. I should have mentionned this third occurence of gdb_catch_sigchld. Your os_unix.i matches mine on Linux,
                                  Message 16 of 19 , May 13, 2004
                                  • 0 Attachment
                                    On 5/10/2004 Malte Neumann wrote:
                                    > [...]
                                    > > Also, could you preprocces os_unix.c and see how these macros
                                    > > are expanded. To do that, simply run:
                                    > >
                                    > > gcc -I. -Iproto -DHAVE_CONFIG_H -E os_unix.c >os_unix.i
                                    > [...]
                                    >
                                    > # 1192 "os_unix.c"
                                    > sigset(18, (void (*)())gdb_catch_sigchld);
                                    >
                                    >
                                    > The line 1192 was originally one of the lines 1117-1119.
                                    >
                                    > I hope I did not mix up your changes at some place.
                                    >

                                    No, actually it's me and my own changes, sorry. I should have mentionned
                                    this third occurence of gdb_catch_sigchld.
                                    Your "os_unix.i" matches mine on Linux, nothing wrong there, thanks.

                                    There does not seem anything wrong with VimGDB code. Let's
                                    concentrate now on Vim code and mch_call_shell() where it crashes.

                                    a) In mch_call_shell() after line 3521 (so it's more clear, I am
                                    using line numbers from the original Vim62 os_unix.c file, not the
                                    patched one):

                                    _exit(EXEC_FAILED); /* exec failed, return failure code */
                                    }
                                    else /* parent */
                                    {
                                    /*
                                    * While child is running, ignore terminating signals.
                                    */
                                    3521 --> catch_signals(SIG_IGN, SIG_ERR);

                                    add at line 3522 after catch_signals():

                                    3522 --> signal(SIGCHLD, SIG_IGN);


                                    b) Another test, after removing the previous change, insert at line 29:
                                    in os_unix.c:

                                    #include "vim.h"
                                    #undef HAVE_SIGALTSTACK <-- 29

                                    #ifdef HAVE_FCNTL_H
                                    # include <fcntl.h>
                                    #endif


                                    If both tests crash, je donne ma langue au chat
                                    ('I give my tongue to the cat', it's french, for when a kid can't find
                                    an answer to a question in a game).


                                    > [...]
                                    > > As a result the input-line window must pop up and display the completion
                                    > > result: 'show annotate'.
                                    >
                                    > I get as a result no input-line window and trying to issue any other gdb
                                    > command (like 'set args' or 'break') I get the answer:
                                    >
                                    > GDB busy: command discarded, please retry
                                    >
                                    > I have to quit VimGDB to finish this state.

                                    As a rule, you should be able to send an interrupt to GDB
                                    (type <CTRL-Z>) and abort the command, without having to
                                    quit VimGDB. If not, it's another bug.



                                    > Maybe I should mention that I use a mapping for the <TAB> key, but I believe
                                    > that on my Linux Box with the same .vimrc the completion works. I have the
                                    > following in my .vimrc concerning the <TAB>:
                                    > [...]

                                    I don't think it matters: VimGDB maps the <TAB> key each time the
                                    input-line window is popped up.


                                    a) What is the GDB version you are using on HPUX ?


                                    b) Check that GDB editing mode is on: run GDB cmd: "show editing"
                                    the result must be:

                                    Editing of command lines as they are typed is on.


                                    c) Check that nothing is wrong with .inputrc: run the Vim command

                                    :edit $INPUTRC

                                    you must see:

                                    set show-all-if-ambiguous on
                                    set completion-query-items 20
                                    Control-u: unix-line-discard


                                    d) Do you have the same problem when doing a completion that
                                    gives multiple results, such as "show e<TAB>" ?


                                    e) Does the input-line window works: to test that, run twice the GDB
                                    "file" command on the same file, you get:

                                    Load new symbol table from "foobar"? (y or n)

                                    and the input-line window _MUST_ pop up.


                                    f) When you run the GDB program by itself (without VimGDB)
                                    and do a completion such as:

                                    (gdb) show ann<TAB>

                                    does the completion result appears on the same line or on a new
                                    different line ?


                                    Xavier...



                                    __________________________________________________________________
                                    Introducing the New Netscape Internet Service.
                                    Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

                                    Netscape. Just the Net You Need.

                                    New! Netscape Toolbar for Internet Explorer
                                    Search from anywhere on the Web and block those annoying pop-ups.
                                    Download now at http://channels.netscape.com/ns/search/install.jsp
                                  • Malte Neumann
                                    ... Congratulations!! This works fine, expect for a minor draw back. When opening a file, before displaying the file, vim says: Hit ENTER of type command to
                                    Message 17 of 19 , May 13, 2004
                                    • 0 Attachment
                                      On Thu, May 13, 2004 at 09:48:01AM -0400, Xavier de Gaye wrote:
                                      >
                                      > On 5/10/2004 Malte Neumann wrote:
                                      > > [...]
                                      > > > Also, could you preprocces os_unix.c and see how these macros
                                      > > > are expanded. To do that, simply run:
                                      > > >
                                      > > > gcc -I. -Iproto -DHAVE_CONFIG_H -E os_unix.c >os_unix.i
                                      > > [...]
                                      > >
                                      > > # 1192 "os_unix.c"
                                      > > sigset(18, (void (*)())gdb_catch_sigchld);
                                      > >
                                      > >
                                      > > The line 1192 was originally one of the lines 1117-1119.
                                      > >
                                      > > I hope I did not mix up your changes at some place.
                                      > >
                                      >
                                      > No, actually it's me and my own changes, sorry. I should have mentionned
                                      > this third occurence of gdb_catch_sigchld.
                                      > Your "os_unix.i" matches mine on Linux, nothing wrong there, thanks.
                                      >
                                      > There does not seem anything wrong with VimGDB code. Let's
                                      > concentrate now on Vim code and mch_call_shell() where it crashes.
                                      >
                                      > a) In mch_call_shell() after line 3521 (so it's more clear, I am
                                      > using line numbers from the original Vim62 os_unix.c file, not the
                                      > patched one):
                                      >
                                      > _exit(EXEC_FAILED); /* exec failed, return failure code */
                                      > }
                                      > else /* parent */
                                      > {
                                      > /*
                                      > * While child is running, ignore terminating signals.
                                      > */
                                      > 3521 --> catch_signals(SIG_IGN, SIG_ERR);
                                      >
                                      > add at line 3522 after catch_signals():
                                      >
                                      > 3522 --> signal(SIGCHLD, SIG_IGN);

                                      Congratulations!! This works fine, expect for a minor draw back. When
                                      opening a file, before displaying the file, vim says:

                                      Hit ENTER of type command to continue.

                                      After hitting Enter the file is displayed.

                                      [some time later...]

                                      - The 'Hit ENTER ...' prompt is only displayed for the terminal version, for
                                      the gui version opening a file works fine.

                                      - Trying to use this VimGDB (gui version) for real debugging once showed
                                      still a crash. Unfortunately I cannot reproduce this behaviour.
                                      I will tell you as soon as I know what usage triggered this crash.


                                      > b) Another test, after removing the previous change, insert at line 29:
                                      > in os_unix.c:
                                      >
                                      > #include "vim.h"
                                      > #undef HAVE_SIGALTSTACK <-- 29
                                      >
                                      > #ifdef HAVE_FCNTL_H
                                      > # include <fcntl.h>
                                      > #endif

                                      This one does not work. Still the same crash.

                                      > If both tests crash, je donne ma langue au chat
                                      > ('I give my tongue to the cat', it's french, for when a kid can't find
                                      > an answer to a question in a game).
                                      >
                                      >
                                      > > [...]
                                      > > > As a result the input-line window must pop up and display the
                                      > > > completion result: 'show annotate'.
                                      > >
                                      > > I get as a result no input-line window and trying to issue any other gdb
                                      > > command (like 'set args' or 'break') I get the answer:
                                      > >
                                      > > GDB busy: command discarded, please retry
                                      > >
                                      > > I have to quit VimGDB to finish this state.
                                      >
                                      > As a rule, you should be able to send an interrupt to GDB
                                      > (type <CTRL-Z>) and abort the command, without having to
                                      > quit VimGDB. If not, it's another bug.

                                      Ok. I didn't try <CTRL-Z>. But it works, when in the input-window, <CTRL-Z>
                                      interrupts the gdb command.


                                      > > Maybe I should mention that I use a mapping for the <TAB> key, but I
                                      > > believe that on my Linux Box with the same .vimrc the completion works.
                                      > > I have the following in my .vimrc concerning the <TAB>:
                                      > > [...]
                                      >
                                      > I don't think it matters: VimGDB maps the <TAB> key each time the
                                      > input-line window is popped up.
                                      >
                                      >
                                      > a) What is the GDB version you are using on HPUX ?

                                      [508] gdb --version
                                      GNU gdb 5.3
                                      [snip]
                                      This GDB was configured as "hppa2.0n-hp-hpux11.00".


                                      > b) Check that GDB editing mode is on: run GDB cmd: "show editing"
                                      > the result must be:
                                      >
                                      > Editing of command lines as they are typed is on.

                                      That's ok, for pure gdb and VimGDB.


                                      > c) Check that nothing is wrong with .inputrc: run the Vim command
                                      >
                                      > :edit $INPUTRC
                                      >
                                      > you must see:
                                      >
                                      > set show-all-if-ambiguous on
                                      > set completion-query-items 20
                                      > Control-u: unix-line-discard

                                      Thats also ok.


                                      > d) Do you have the same problem when doing a completion that
                                      > gives multiple results, such as "show e<TAB>" ?

                                      Trying a completion with multiple results does not work either, the
                                      possibilities are shown in the gdb window, the input window is closed and
                                      gdb is busy. When opening the input window again, the started line is not
                                      shown.


                                      > e) Does the input-line window works: to test that, run twice the GDB
                                      > "file" command on the same file, you get:
                                      >
                                      > Load new symbol table from "foobar"? (y or n)
                                      >
                                      > and the input-line window _MUST_ pop up.

                                      The input-line window DOES pop up, but when entering y and <ENTER> the
                                      window closes and nothing happens. After that gdb is again busy. When
                                      interrupting gdb after that, the symbols are loaded.


                                      > f) When you run the GDB program by itself (without VimGDB)
                                      > and do a completion such as:
                                      >
                                      > (gdb) show ann<TAB>
                                      >
                                      > does the completion result appears on the same line or on a new
                                      > different line ?

                                      For a completion with only one possibility the word is completed on the same
                                      line. For completions with several possibilities ('show e') after the
                                      second <TAB> the possibilities are show on a new line and a new prompt:
                                      (gdb) show e
                                      is displayed.


                                      Malte

                                      --
                                      --------------------------------------------------------------------------
                                      Malte Neumann
                                      --------------------------------------------------------------------------
                                      Institut fuer Baustatik / Institute of Structural Mechanics
                                      Prof. Dr.-Ing. Ekkehard Ramm
                                      Universitaet Stuttgart / University of Stuttgart

                                      Pfaffenwaldring 7, D-70550 Stuttgart, Germany

                                      mailto:neumann@...-stuttgart.de phone: ++49-711-685-6121
                                      http://www.uni-stuttgart.de/ibs/members/neumann/ fax: ++49-711-685-6130
                                      --------------------------------------------------------------------------
                                    • Xavier de Gaye
                                      On 5/13/2004 Malte Neumann wrote: ... After setting SIGCHLD to SIG_IGN at line 3522 above, vim (not gvim) executes _ONLY_ the following lines before SIGCHLD is
                                      Message 18 of 19 , May 26, 2004
                                      • 0 Attachment
                                        On 5/13/2004 Malte Neumann wrote:
                                        On Thu, May 13, 2004 at 09:48:01AM -0400, Xavier de Gaye wrote:
                                        > [...]
                                        > > a) In mch_call_shell() after line 3521 (so it's more clear, I am
                                        > > using line numbers from the original Vim62 os_unix.c file, not the
                                        > > patched one):
                                        > >
                                        > > _exit(EXEC_FAILED); /* exec failed, return failure code */
                                        > > }
                                        > > else /* parent */
                                        > > {
                                        > > /*
                                        > > * While child is running, ignore terminating signals.
                                        > > */
                                        > > 3521 --> catch_signals(SIG_IGN, SIG_ERR);
                                        > >
                                        > > add at line 3522 after catch_signals():
                                        > >
                                        > > 3522 --> signal(SIGCHLD, SIG_IGN);
                                        >
                                        > Congratulations!! This works fine, expect for a minor draw back. When
                                        > opening a file, before displaying the file, vim says:
                                        >

                                        After setting SIGCHLD to SIG_IGN at line 3522 above, vim (not gvim)
                                        executes _ONLY_ the following lines before SIGCHLD is set
                                        back again to gdb_catch_sigchld() in set_signals():

                                        while (wait_pid != pid)
                                        {
                                        wait_pid = wait(&status);
                                        if (wait_pid <= 0 && errno == ECHILD)
                                        break;
                                        }

                                        /*
                                        * Set to raw mode right now, otherwise a CTRL-C after
                                        * catch_signals() will kill Vim.
                                        */
                                        if (tmode == TMODE_RAW)
                                        settmode(TMODE_RAW);
                                        did_settmode = TRUE;
                                        --> set_signals(); <-- SIGCHLD back to gdb_catch_sigchld()


                                        What do the man pages say about the argument to wait(), is it a
                                        pointer to an int ?

                                        Does gcc give any warning on these lines when compiling os_unix.c ?

                                        With the fix in line 3522 above, can you have two GDB consecutive
                                        sessions within the same VimGDB session ?
                                        use the GDB "quit" command, to end the current GDB session: this
                                        will test VimGDB's handling of waitpid().

                                        Ah, and also another check we have not made yet:
                                        remove line 3522 above
                                        replace gdb_sigchld() contents in gdb.c with just one
                                        statement:
                                        return FALSE;
                                        does it crash ?



                                        > [...]
                                        > Ok. I didn't try <CTRL-Z>. But it works, when in the input-window, <CTRL-Z>
                                        > interrupts the gdb command.
                                        > [...]

                                        You can also type <CTRL-Z> from anywhere, not only the input-window, when
                                        gdb_mappings.vim has been sourced and mappings toggled with <F7>.



                                        > [...]
                                        > > e) Does the input-line window works: to test that, run twice the GDB
                                        > > "file" command on the same file, you get:
                                        > >
                                        > > Load new symbol table from "foobar"? (y or n)
                                        > >
                                        > > and the input-line window _MUST_ pop up.
                                        >
                                        > The input-line window DOES pop up, but when entering y and <ENTER> the
                                        > window closes and nothing happens. After that gdb is again busy.
                                        >
                                        > interrupting gdb after that, the symbols are loaded.


                                        Do you have 'y' echoed after the prompt (y or n) ?
                                        (gdb) file foobar
                                        Load new symbol table from "foobar"? (y or n) y
                                        Reading symbols from foobar...done.
                                        (gdb)


                                        Another test is to "define" a sequence of commands, like this:

                                        (gdb) define foobar
                                        Type commands for definition of "foobar".
                                        End with a line saying just "end".
                                        >print anything
                                        >end
                                        (gdb)

                                        Does this work ?


                                        Try please, to prevent commands from being discarded and remove
                                        "GDB busy: command discarded, please retry" messages:
                                        in gdb.c: in gdb_docmd() comment out 5 lines:

                                        /* accept one cmd at a time, allow intr */
                                        if (cmd != NULL && *cmd != NUL && *(cmd + STRLEN(cmd) - 1) == KEY_INTERUPT)
                                        this->oob.state |= OS_INTR;
                                        /* COMMENT OUT THESE 5 LINES
                                        * else if (this->oob.state & OS_CMD)
                                        * {
                                        * give_warning("GDB busy: command discarded, please retry", TRUE);
                                        * return;
                                        * }
                                        * END COMMENT OUT THESE 5 LINES */
                                        else
                                        this->oob.idx = -1; /* needed when last oob was aborted with OS_QUITs */
                                        this->oob.state |= OS_CMD;

                                        Does this change anything in the previous tests ?


                                        Xavier...



                                        __________________________________________________________________
                                        Introducing the New Netscape Internet Service.
                                        Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

                                        Netscape. Just the Net You Need.

                                        New! Netscape Toolbar for Internet Explorer
                                        Search from anywhere on the Web and block those annoying pop-ups.
                                        Download now at http://channels.netscape.com/ns/search/install.jsp
                                      • Malte Neumann
                                        Hi Xavier, soory for this very long time of silence. I was really busy at work for some time, then on holiday,.... But now after using this more or less
                                        Message 19 of 19 , Aug 24 8:40 AM
                                        • 0 Attachment
                                          Hi Xavier,

                                          soory for this very long time of silence. I was really busy at work for some
                                          time, then on holiday,....

                                          But now after using this more or less working VimGDB for some time I believe
                                          it would be nice to have the completely working thing.


                                          To keep things clear, I started again from the pure Vim 6.2 code and the
                                          patches Version 6.

                                          This original version crashes when opening a file with ':e' (both vim and
                                          gvim).


                                          The only change I made to the code is adding the line 3522 as described
                                          below.


                                          On Wed, May 26, 2004 at 09:23:59AM -0400, Xavier de Gaye wrote:
                                          >
                                          > On 5/13/2004 Malte Neumann wrote:
                                          > On Thu, May 13, 2004 at 09:48:01AM -0400, Xavier de Gaye wrote:
                                          > > > a) In mch_call_shell() after line 3521 (so it's more clear, I am
                                          > > > using line numbers from the original Vim62 os_unix.c file, not the
                                          > > > patched one):
                                          > > >
                                          > > > _exit(EXEC_FAILED); /* exec failed, return failure code */
                                          > > > }
                                          > > > else /* parent */
                                          > > > {
                                          > > > /*
                                          > > > * While child is running, ignore terminating signals.
                                          > > > */
                                          > > > 3521 --> catch_signals(SIG_IGN, SIG_ERR);
                                          > > >
                                          > > > add at line 3522 after catch_signals():
                                          > > >
                                          > > > 3522 --> signal(SIGCHLD, SIG_IGN);

                                          This version now behaves much better:

                                          With gvim it is now possible to open files, start gdb, and step through the
                                          code. It is even possible to quit gdb and restart it afterwards.

                                          vim does not open any files, it just hangs after displaying the line:
                                          "main.c" 162L, 5409C


                                          > After setting SIGCHLD to SIG_IGN at line 3522 above, vim (not gvim)
                                          > executes _ONLY_ the following lines before SIGCHLD is set
                                          > back again to gdb_catch_sigchld() in set_signals():
                                          >
                                          > while (wait_pid != pid)
                                          > {
                                          > wait_pid = wait(&status);
                                          > if (wait_pid <= 0 && errno == ECHILD)
                                          > break;
                                          > }
                                          >
                                          > /*
                                          > * Set to raw mode right now, otherwise a CTRL-C after
                                          > * catch_signals() will kill Vim.
                                          > */
                                          > if (tmode == TMODE_RAW)
                                          > settmode(TMODE_RAW);
                                          > did_settmode = TRUE;
                                          > --> set_signals(); <-- SIGCHLD back to gdb_catch_sigchld()
                                          >
                                          >
                                          > What do the man pages say about the argument to wait(), is it a
                                          > pointer to an int ?

                                          'man 2 wait' gives the following:

                                          wait(2)

                                          NAME
                                          wait, waitpid - wait for child process to stop or terminate

                                          SYNOPSIS
                                          #include <sys/types.h> OH
                                          #include <sys/wait.h>

                                          pid_t wait(int *stat_loc);

                                          pid_t waitpid(pid_t pid, int *stat_loc, int options);

                                          So, it is an pointer to an int.


                                          > Does gcc give any warning on these lines when compiling os_unix.c ?

                                          The only warning I get when compiling os_unix.c is the following:

                                          os_unix.c: In function `RealWaitForChar':
                                          os_unix.c:4273: warning: passing arg 1 of `poll' from incompatible pointer
                                          type

                                          where line 4273 is the following:
                                          ret = poll(&fds, nfd, (int)msec);


                                          > With the fix in line 3522 above, can you have two GDB consecutive
                                          > sessions within the same VimGDB session ?
                                          > use the GDB "quit" command, to end the current GDB session: this
                                          > will test VimGDB's handling of waitpid().

                                          Yes, see above.

                                          > Ah, and also another check we have not made yet:
                                          > remove line 3522 above
                                          > replace gdb_sigchld() contents in gdb.c with just one
                                          > statement:
                                          > return FALSE;
                                          > does it crash ?

                                          vim crashes in the same way as the original does.

                                          gvim does not crash, the file is opened, but the <F7> to map the keys does
                                          not work.


                                          > > [...]
                                          > > Ok. I didn't try <CTRL-Z>. But it works, when in the input-window, <CTRL-Z>
                                          > > interrupts the gdb command.
                                          > > [...]
                                          >
                                          > You can also type <CTRL-Z> from anywhere, not only the input-window, when
                                          > gdb_mappings.vim has been sourced and mappings toggled with <F7>.
                                          >
                                          >
                                          >
                                          > > [...]
                                          > > > e) Does the input-line window works: to test that, run twice the GDB
                                          > > > "file" command on the same file, you get:
                                          > > >
                                          > > > Load new symbol table from "foobar"? (y or n)
                                          > > >
                                          > > > and the input-line window _MUST_ pop up.
                                          > >
                                          > > The input-line window DOES pop up, but when entering y and <ENTER> the
                                          > > window closes and nothing happens. After that gdb is again busy.
                                          > >
                                          > > interrupting gdb after that, the symbols are loaded.
                                          >
                                          >
                                          > Do you have 'y' echoed after the prompt (y or n) ?
                                          > (gdb) file foobar
                                          > Load new symbol table from "foobar"? (y or n) y
                                          > Reading symbols from foobar...done.
                                          > (gdb)

                                          No, the 'y' is not echod.

                                          The output looks like this:

                                          (gdb) Load new symbol table from "foobar.debg"? (y or n) Reading symbols from ~/wdir/ccarat_fluidfast/cca_11_seq.debg...done.
                                          (gdb)

                                          Everything in one line, the part 'Reading symbols...' appears after
                                          interrupting gdb.

                                          > Another test is to "define" a sequence of commands, like this:
                                          >
                                          > (gdb) define foobar
                                          > Type commands for definition of "foobar".
                                          > End with a line saying just "end".
                                          > >print anything
                                          > >end
                                          > (gdb)
                                          >
                                          > Does this work ?

                                          This DOES work, but the commands 'print anything' and 'end' are not echoed in
                                          the gdb-output window. Just the second prompt appears after entering 'print
                                          anything':

                                          (gdb) Type commands for definition of "barfoo".
                                          End with a line saying just "end".
                                          >>(gdb)


                                          > Try please, to prevent commands from being discarded and remove
                                          > "GDB busy: command discarded, please retry" messages:
                                          > in gdb.c: in gdb_docmd() comment out 5 lines:
                                          >
                                          > /* accept one cmd at a time, allow intr */
                                          > if (cmd != NULL && *cmd != NUL && *(cmd + STRLEN(cmd) - 1) == KEY_INTERUPT)
                                          > this->oob.state |= OS_INTR;
                                          > /* COMMENT OUT THESE 5 LINES
                                          > * else if (this->oob.state & OS_CMD)
                                          > * {
                                          > * give_warning("GDB busy: command discarded, please retry", TRUE);
                                          > * return;
                                          > * }
                                          > * END COMMENT OUT THESE 5 LINES */
                                          > else
                                          > this->oob.idx = -1; /* needed when last oob was aborted with OS_QUITs */
                                          > this->oob.state |= OS_CMD;
                                          >
                                          > Does this change anything in the previous tests ?

                                          No, it does change anything in the behaviour of reloading the symbols or
                                          defining a sequence of commands.


                                          Malte


                                          --
                                          Malte Neumann
                                          Institute of Structural Mechanics, University of Stuttgart, Germany
                                          http://www.uni-stuttgart.de/ibs/members/neumann/
                                        Your message has been successfully submitted and would be delivered to recipients shortly.