This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb/863: gdb says "No breakpoint number -1" on "continue 2" command


>Number:         863
>Category:       gdb
>Synopsis:       gdb says "No breakpoint number -1" on "continue 2" command
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 02 20:58:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     mec@shout.net
>Release:        gdb HEAD%20021125
>Organization:
>Environment:
target = native, host = i686-pc-linux-gnu%rh-8, gdb = HEAD%20021125, gcc = 3.2.1, binutils = 2.13.1, glibc = 2.2.93-5-rh, gformat = dwarf-2.

Happens with many different gdb's, gcc's, and binutils'.
>Description:
This problem happens in test script gdb.base/ena-dis-br.exp.  The test script issues these commands:

  break 79
  continue 2
  next
  continue 2

gdb responds to the second "continue" with "No breakpoint number -1", which is bogus. There appears to be no harm besides the bogus error.

This bug has been bugging me because it works with gcc 3.0.4 and earlier, and fails with gcc 3.1 and later, so that modern versions of gcc produce worse test results than early versions of gcc.  This looks bad in my test bed and (falsely) points to some regressive change in gcc.

Here are gdb.log excerpts.  The interesting line is just before the last result, on the second "continue" command.

Here is a gdb.log excerpt for a PASS result:

  # gdb HEAD, gcc 3.0.4, binutils 2.13.1, glibc 2.2.93-5-rh, dwarf-2
  (gdb) break 79
  Breakpoint 14 at 0x8048560: file /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/break.c, line 79.
  (gdb) PASS: gdb.base/ena-dis-br.exp: prepare to continue with ignore count
  continue 2
  Will ignore next crossing of breakpoint 13.  Continuing.

  Breakpoint 14, main (argc=1, argv=0xbffff8d4, envp=0xbffff8dc) at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/break.c:79
  79        printf ("%d\n", factorial (atoi ("6")));
  (gdb) PASS: gdb.base/ena-dis-br.exp: continue with ignore count
  next
  720
  81        marker1 ();
  (gdb) PASS: gdb.base/ena-dis-br.exp: step after continue with ignore count
  continue 2
  Not stopped at any breakpoint; argument ignored.
  Continuing.

  Program exited normally.
  (gdb) PASS: gdb.base/ena-dis-br.exp: continue with ignore count, not stopped at bpt

Here is a gdb.log excerpt for an XFAIL result:

  # gdb HEAD, gcc 3.2.1, binutils 2.13.1, glibc 2.2.93-5-rh, dwarf-2
  (gdb) break 79
  Breakpoint 14 at 0x804844d: file /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/break.c, line 79.
  (gdb) PASS: gdb.base/ena-dis-br.exp: prepare to continue with ignore count
  continue 2
  Will ignore next crossing of breakpoint 13.  Continuing.

  Breakpoint 14, main (argc=1, argv=0xbffff8d4, envp=0xbffff8dc) at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/break.c:79
  79        printf ("%d\n", factorial (atoi ("6")));
  (gdb) PASS: gdb.base/ena-dis-br.exp: continue with ignore count
  next
  720
  81        marker1 ();
  (gdb) PASS: gdb.base/ena-dis-br.exp: step after continue with ignore count
  continue 2
  No breakpoint number -1.
  (gdb) XFAIL: gdb.base/ena-dis-br.exp: (DTS'd) continue with ignore count, not stopped at bpt (PRMS hppa_*_*)

For some reason, the test script reports "No breakpoint number -1" as an XFAIL, although there is a comment about it:

  # ??rehrauer: Huh.  This appears to be an actual bug.  (No big
  # surprise, since this feature hasn't been tested...)  Looks like
  # GDB is currently trying to set the ignore count of bp # -1!

This file, ena-dis-br.exp, came from the HP merge.  I think that this is really a gdb bug and the comment is right and the "xfail" is wrong.

This test is sensitive to gcc version.  The test result is PASS with gcc 2.95.3, gcc 3.0.4, and the vendor compiler, gcc 3.2-7-rh.  The test result is XFAIL with gcc 3.1, gcc 3.1.1, gcc 3.2, gcc 3.2.1, gcc gcc-3_2-branch%20021125, and gcc HEAD%20021125.  The test is not sensitive to gdb version, binutils version, or debugging format.
>How-To-Repeat:
Run gdb.base/ena-dis-br.exp with one of the compilers listed above (such as gcc 3.2.1).
>Fix:
The cause looks simple.  Here is code from infcmd.c:continue_command():

  /* If have argument (besides '&'), set proceed count of breakpoint
     we stopped at.  */
  if (proc_count_exp != NULL)
    {
      bpstat bs = stop_bpstat;
      int num = bpstat_num (&bs);
      if (num == 0 && from_tty)
        {
          printf_filtered
            ("Not stopped at any breakpoint; argument ignored.\n");
        }
      while (num != 0)
        {
          set_ignore_count (num,
                            parse_and_eval_long (proc_count_exp) - 1,
                            from_tty);
          /* set_ignore_count prints a message ending with a period.
             So print two spaces before "Continuing.".  */
          if (from_tty)
            printf_filtered ("  ");
          num = bpstat_num (&bs);
        }
    }

But bpstat_num can return -1 if the breakpoint has been deleted.

So the fix might be as simple as:

  diff -u -r -N ORIG-HEAD/src/gdb/infcmd.c HEAD/src/gdb/infcmd.c
  --- ORIG-HEAD/src/gdb/infcmd.c         2002-11-24 14:48:12.000000000 -0500
  +++ HEAD/src/gdb/infcmd.c     2002-12-02 02:44:26.000000000 -0500
  @@ -505,12 +505,13 @@
       {
         bpstat bs = stop_bpstat;
         int num = bpstat_num (&bs);
  -      if (num == 0 && from_tty)
  +      if (num <= 0 && from_tty)
           {
  +          /* num can be either -1 or 0 if we are not at a breakpoint.  */
              printf_filtered
                ("Not stopped at any breakpoint; argument ignored.\n");
  -    while (num != 0)
  +    while (num > 0)
         {
           set_ignore_count (num,
                             parse_and_eval_long (proc_count_exp) - 1,

... or, the fix might not be that simple!

The interesting question: why does the test result depend on the gcc version?
>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]