Re: gdb 5.2 removes the conditional breakpoints

Re: gdb 5.2 removes the conditional breakpoints

[Michael Veksler]

/References/: <20020322095020.A12445@lucon.org 
<http://sources.redhat.com/ml/gdb/2002-03/msg00196.html> > 
<3C9B76F5.6050809@cygnus.com 
<http://sources.redhat.com/ml/gdb/2002-03/msg00198.html> >


On Fri, Mar 22, 2002 at 01:24:53PM -0500, Andrew Cagney wrote:
> > When I do
> > 
> > (gdb) b 100
> > (gdb) cond 1 i == 3
> > (gdb) r
> > (gdb) r
> > 
> > gdb 5.2 will remove the conditional breakpoints on Linux/x86 after I
> > restart the debug session. Am I the only one who sees it?
> 
> It would be very helpful if you could illustrate this problem by 
> submitting a real testcase.  That way people can run it and check 
> before/after effects on various platforms and GDB releases.
> 

Here are the instructions for reproducing this annoying problem:

    // Debugged source:
    typedef int operation(int val);

    int f(operation * op, int value)
    {
        return op(value);
    }

    int nop(int val)
    {
       return val;
    }

    int main()
    {
        return f(nop, 5);
    }
    // End source

Compile it on Linux using gcc 3.0.4 or  redhat's 2.96 (did not test it 
on other versions).
(gdb) b main
(gdb) r
Breakpoint 1, main () at t.c:15
15         return f(nop, 5);
(gdb) s
f (op=0x8048448 <nop>, value=5) at t.c:5
5          return op(value);
(gdb) b
Breakpoint 2 at 0x8048432: file t.c, line 5.
(gdb) cond 2 op(value) == value
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: .....
Breakpoint 1, main () at t.c:15
15         return f(nop, 5);
(gdb) info b
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x0804845a in main at t.c:15
        breakpoint already hit 1 time
(gdb) q

----- Breakpoint 2 lost !!! ----


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

Re: gdb 5.2 removes the conditional breakpoints

[H . J . Lu]

On Wed, Apr 10, 2002 at 10:52:51AM +0300, Michael Veksler wrote:
> /References/: <20020322095020.A12445@lucon.org 
> <http://sources.redhat.com/ml/gdb/2002-03/msg00196.html> > 
> <3C9B76F5.6050809@cygnus.com 
> <http://sources.redhat.com/ml/gdb/2002-03/msg00198.html> >
> 
> 
> On Fri, Mar 22, 2002 at 01:24:53PM -0500, Andrew Cagney wrote:
> > > When I do
> > > 
> > > (gdb) b 100
> > > (gdb) cond 1 i == 3
> > > (gdb) r
> > > (gdb) r
> > > 
> > > gdb 5.2 will remove the conditional breakpoints on Linux/x86 after I
> > > restart the debug session. Am I the only one who sees it?
> > 
> > It would be very helpful if you could illustrate this problem by 
> > submitting a real testcase.  That way people can run it and check 
> > before/after effects on various platforms and GDB releases.
> > 
> 
> Here are the instructions for reproducing this annoying problem:
> 
>     // Debugged source:
>     typedef int operation(int val);
> 
>     int f(operation * op, int value)
>     {
>         return op(value);
>     }
> 
>     int nop(int val)
>     {
>        return val;
>     }
> 
>     int main()
>     {
>         return f(nop, 5);
>     }
>     // End source
> 
> Compile it on Linux using gcc 3.0.4 or  redhat's 2.96 (did not test it 
> on other versions).
> (gdb) b main
> (gdb) r
> Breakpoint 1, main () at t.c:15
> 15         return f(nop, 5);
> (gdb) s
> f (op=0x8048448 <nop>, value=5) at t.c:5
> 5          return op(value);
> (gdb) b
> Breakpoint 2 at 0x8048432: file t.c, line 5.

Thanks for the testcase. Basically, we deleted all break points set
with "break" when we restart. It is a very bad regression from gdb
4.17. Here is a patch. May I check it into gdb 5.2?

Thanks.


H.J.
----
2002-04-17  H.J. Lu  (hjl@gnu.org)

	* breakpoint.c (create_thread_event_breakpoint): Use xasprintf.
	(create_breakpoints): Make sure the addr_string field is not
	NULL.

--- gdb/breakpoint.c.break	Wed Mar  6 22:30:42 2002
+++ gdb/breakpoint.c	Wed Apr 17 16:50:18 2002
@@ -3859,14 +3859,12 @@ struct breakpoint *
 create_thread_event_breakpoint (CORE_ADDR address)
 {
   struct breakpoint *b;
-  char addr_string[80];		/* Surely an addr can't be longer than that. */
 
   b = create_internal_breakpoint (address, bp_thread_event);
   
   b->enable_state = bp_enabled;
   /* addr_string has to be used or breakpoint_re_set will delete me.  */
-  sprintf (addr_string, "*0x%s", paddr (b->address));
-  b->addr_string = xstrdup (addr_string);
+  xasprintf (&b->addr_string, "*0x%s", paddr (b->address));
 
   return b;
 }
@@ -4422,7 +4420,10 @@ create_breakpoints (struct symtabs_and_l
 	b->number = breakpoint_count;
 	b->cond = cond[i];
 	b->thread = thread;
-	b->addr_string = addr_string[i];
+	if (addr_string[i])
+	  b->addr_string = addr_string[i];
+	else
+	  xasprintf (&b->addr_string, "%s:%d", b->source_file, b->line_number);
 	b->cond_string = cond_string[i];
 	b->ignore_count = ignore_count;
 	b->enable_state = bp_enabled;

PATCH: Fix restarting breakpoint (Re: gdb 5.2 removes the conditional breakpoints)

[H . J . Lu]

On Wed, Apr 17, 2002 at 04:57:56PM -0700, H . J . Lu wrote:
> On Wed, Apr 10, 2002 at 10:52:51AM +0300, Michael Veksler wrote:
> > /References/: <20020322095020.A12445@lucon.org 
> > <http://sources.redhat.com/ml/gdb/2002-03/msg00196.html> > 
> > <3C9B76F5.6050809@cygnus.com 
> > <http://sources.redhat.com/ml/gdb/2002-03/msg00198.html> >
> > 
> > 
> > On Fri, Mar 22, 2002 at 01:24:53PM -0500, Andrew Cagney wrote:
> > > > When I do
> > > > 
> > > > (gdb) b 100
> > > > (gdb) cond 1 i == 3
> > > > (gdb) r
> > > > (gdb) r
> > > > 
> > > > gdb 5.2 will remove the conditional breakpoints on Linux/x86 after I
> > > > restart the debug session. Am I the only one who sees it?
> > > 
> > > It would be very helpful if you could illustrate this problem by 
> > > submitting a real testcase.  That way people can run it and check 
> > > before/after effects on various platforms and GDB releases.
> > > 
> > 
> > Here are the instructions for reproducing this annoying problem:
> > 
> >     // Debugged source:
> >     typedef int operation(int val);
> > 
> >     int f(operation * op, int value)
> >     {
> >         return op(value);
> >     }
> > 
> >     int nop(int val)
> >     {
> >        return val;
> >     }
> > 
> >     int main()
> >     {
> >         return f(nop, 5);
> >     }
> >     // End source
> > 
> > Compile it on Linux using gcc 3.0.4 or  redhat's 2.96 (did not test it 
> > on other versions).
> > (gdb) b main
> > (gdb) r
> > Breakpoint 1, main () at t.c:15
> > 15         return f(nop, 5);
> > (gdb) s
> > f (op=0x8048448 <nop>, value=5) at t.c:5
> > 5          return op(value);
> > (gdb) b
> > Breakpoint 2 at 0x8048432: file t.c, line 5.
> 
> Thanks for the testcase. Basically, we deleted all break points set
> with "break" when we restart. It is a very bad regression from gdb
> 4.17. Here is a patch. May I check it into gdb 5.2?
> 
> Thanks.
> 
> 
> H.J.
> ----
> 2002-04-17  H.J. Lu  (hjl@gnu.org)
> 
> 	* breakpoint.c (create_thread_event_breakpoint): Use xasprintf.
> 	(create_breakpoints): Make sure the addr_string field is not
> 	NULL.
> 

Here is an update. It just uses

	xasprintf (&b->addr_string, "*0x%s", paddr (b->address));

H.J.
---
2002-04-17  H.J. Lu  (hjl@gnu.org)

	* breakpoint.c (create_thread_event_breakpoint): Use xasprintf.
	(create_breakpoints): Make sure the addr_string field is not
	NULL.

--- gdb/breakpoint.c.break	Wed Mar  6 22:30:42 2002
+++ gdb/breakpoint.c	Wed Apr 17 17:29:58 2002
@@ -3859,14 +3859,12 @@ struct breakpoint *
 create_thread_event_breakpoint (CORE_ADDR address)
 {
   struct breakpoint *b;
-  char addr_string[80];		/* Surely an addr can't be longer than that. */
 
   b = create_internal_breakpoint (address, bp_thread_event);
   
   b->enable_state = bp_enabled;
   /* addr_string has to be used or breakpoint_re_set will delete me.  */
-  sprintf (addr_string, "*0x%s", paddr (b->address));
-  b->addr_string = xstrdup (addr_string);
+  xasprintf (&b->addr_string, "*0x%s", paddr (b->address));
 
   return b;
 }
@@ -4422,7 +4420,12 @@ create_breakpoints (struct symtabs_and_l
 	b->number = breakpoint_count;
 	b->cond = cond[i];
 	b->thread = thread;
-	b->addr_string = addr_string[i];
+	if (addr_string[i])
+	  b->addr_string = addr_string[i];
+	else
+	  /* addr_string has to be used or breakpoint_re_set will delete
+	     me.  */
+	  xasprintf (&b->addr_string, "*0x%s", paddr (b->address));
 	b->cond_string = cond_string[i];
 	b->ignore_count = ignore_count;
 	b->enable_state = bp_enabled;

Re: gdb 5.2 removes the conditional breakpoints

[Andrew Cagney]

> 
> May I check it into gdb 5.2?

No.  5,2 is effectivly frozen.  I've the README file to fix, that is it.

Andrew

Re: gdb 5.2 removes the conditional breakpoints

[H . J . Lu]

On Wed, Apr 17, 2002 at 08:34:54PM -0400, Andrew Cagney wrote:
> > 
> > May I check it into gdb 5.2?
> 
> No.  5,2 is effectivly frozen.  I've the README file to fix, that is it.
> 

It works with gdb 4.17 and someone broke it in 5.x. How long does it
take to fix it?


H.J.

Re: gdb 5.2 removes the conditional breakpoints

[Andrew Cagney]

> On Wed, Apr 17, 2002 at 08:34:54PM -0400, Andrew Cagney wrote:
> 
>> > 
>> > May I check it into gdb 5.2?
> 
>> 
>> No.  5,2 is effectivly frozen.  I've the README file to fix, that is it.
>> 
> 
> 
> It works with gdb 4.17 and someone broke it in 5.x. How long does it
> take to fix it?

(looks under table, nope, no fire ...)

H.J. This ``very bad regression from gdb 4,17'' that must be in 5,2 has 
been around for ~4 years now without anyone even thinking to report it! 
Perhaphs it isn't so bad after all :-)

BTW, a real .exp testcase?

Andrew