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

Re: VimGDB and ifndef HAVE_SELECT

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.