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

Re: VimGDB and ifndef HAVE_SELECT

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 of 19 , Aug 24, 2004
                                • 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.