gdb 5.2 removes the conditional breakpoints

gdb 5.2 removes the conditional breakpoints

[H . J . Lu]

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?


H.J.

Re: gdb 5.2 removes the conditional breakpoints

[Andrew Cagney]

> 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.

Andrew

Re: gdb 5.2 removes the conditional breakpoints

[Daniel Jacobowitz]

On Fri, Mar 22, 2002 at 09:50:20AM -0800, H . J . Lu 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?

Yes.  It works for me.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb 5.2 removes the conditional breakpoints

[H . J . Lu]

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.
> 

It usually happened when I need it the most, like debugging glibc, gcc
and gdb :-). But it is hard to reproduce it when I want to. I will keep
an eye on it.


H.J.

Re: gdb 5.2 removes the conditional breakpoints

[Daniel Jacobowitz]

On Thu, Apr 18, 2002 at 10:34:44AM -0700, H . J . Lu wrote:
> On Thu, Apr 18, 2002 at 01:23:24PM -0400, Daniel Jacobowitz wrote:
> > On Thu, Apr 18, 2002 at 09:30:59AM -0700, H . J . Lu wrote:
> > > On Thu, Apr 18, 2002 at 02:08:41PM +0300, Eli Zaretskii wrote:
> > > > 
> > > > On Thu, 18 Apr 2002, Michael Veksler wrote:
> > > > 
> > > > > Your argument that "5,2 has been around for ~4
> > > > > years" does not hold water, how many people have been using 5.2 ?
> > > > 
> > > > You misunderstood: Andrew said that between 4.17 and 5.2, all versions of 
> > > > GDB had this bug.  Those versions in between are in use for 4 years, not 
> > > > version 5.2 (which wasn't released yet).
> > > > 
> > > 
> > > Between 4.17 and 5.2, 4.18 and 5.0 are basically broken for Linux. I
> > > only started using 5.1 a few months ago. For me, this regression is
> > > relatively new to my gdb.
> > 
> > That's just untrue.  I used both 4.18 and 5.0 extensively on GNU/Linux
> > systems, and they worked quite well.
> > 
> 
> Are you using linuxthreads and hardware watchpoints? Here is one thread
> on this:
> 
> http://sources.redhat.com/ml/gdb/2001-09/msg00138.html

No.  That is not such a critical feature that I would call it
"basically broken", and more was fixed by 5.0 that it was worth
upgrading.

That message is about a regression in 5.1 from 4.18, which completely
conflicts with what you said above.  It was fixed for 5.2, as far as I
know.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb 5.2 removes the conditional breakpoints

[H . J . Lu]

On Thu, Apr 18, 2002 at 01:23:24PM -0400, Daniel Jacobowitz wrote:
> On Thu, Apr 18, 2002 at 09:30:59AM -0700, H . J . Lu wrote:
> > On Thu, Apr 18, 2002 at 02:08:41PM +0300, Eli Zaretskii wrote:
> > > 
> > > On Thu, 18 Apr 2002, Michael Veksler wrote:
> > > 
> > > > Your argument that "5,2 has been around for ~4
> > > > years" does not hold water, how many people have been using 5.2 ?
> > > 
> > > You misunderstood: Andrew said that between 4.17 and 5.2, all versions of 
> > > GDB had this bug.  Those versions in between are in use for 4 years, not 
> > > version 5.2 (which wasn't released yet).
> > > 
> > 
> > Between 4.17 and 5.2, 4.18 and 5.0 are basically broken for Linux. I
> > only started using 5.1 a few months ago. For me, this regression is
> > relatively new to my gdb.
> 
> That's just untrue.  I used both 4.18 and 5.0 extensively on GNU/Linux
> systems, and they worked quite well.
> 

Are you using linuxthreads and hardware watchpoints? Here is one thread
on this:

http://sources.redhat.com/ml/gdb/2001-09/msg00138.html


H.J.

Re: gdb 5.2 removes the conditional breakpoints

[Daniel Jacobowitz]

On Thu, Apr 18, 2002 at 09:30:59AM -0700, H . J . Lu wrote:
> On Thu, Apr 18, 2002 at 02:08:41PM +0300, Eli Zaretskii wrote:
> > 
> > On Thu, 18 Apr 2002, Michael Veksler wrote:
> > 
> > > Your argument that "5,2 has been around for ~4
> > > years" does not hold water, how many people have been using 5.2 ?
> > 
> > You misunderstood: Andrew said that between 4.17 and 5.2, all versions of 
> > GDB had this bug.  Those versions in between are in use for 4 years, not 
> > version 5.2 (which wasn't released yet).
> > 
> 
> Between 4.17 and 5.2, 4.18 and 5.0 are basically broken for Linux. I
> only started using 5.1 a few months ago. For me, this regression is
> relatively new to my gdb.

That's just untrue.  I used both 4.18 and 5.0 extensively on GNU/Linux
systems, and they worked quite well.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb 5.2 removes the conditional breakpoints

[H . J . Lu]

On Thu, Apr 18, 2002 at 02:08:41PM +0300, Eli Zaretskii wrote:
> 
> Bugs which have relatively safe fixes will be fixed on the branch.  Bugs 
> that don't have safe fixes will have to wait for the next release.  New 
> features (as opposed to bugfixes) will have to wait, period.
> 
> Please be aware of the downside of fixing everything indiscriminately: it 
> means that GDB 5.2 will never be released, since ``there's always one 
> more bug''.  So what will go into the branch and what won't is a 
> judgement call, not something that is self-evident.
> 

That is a regression and a very bad one we are talking about. I believe
it is perfectly fine to delay a release to fix regressions. Otherwise,
people may find the new gdb less useful than the old ones or people
may say the new gdb is worse than the old ones.

BTW, I agree we shouldn't fix old bugs nor add new features on branch.


H.J.

Re: gdb 5.2 removes the conditional breakpoints

[H . J . Lu]

On Thu, Apr 18, 2002 at 02:08:41PM +0300, Eli Zaretskii wrote:
> 
> On Thu, 18 Apr 2002, Michael Veksler wrote:
> 
> > Your argument that "5,2 has been around for ~4
> > years" does not hold water, how many people have been using 5.2 ?
> 
> You misunderstood: Andrew said that between 4.17 and 5.2, all versions of 
> GDB had this bug.  Those versions in between are in use for 4 years, not 
> version 5.2 (which wasn't released yet).
> 

Between 4.17 and 5.2, 4.18 and 5.0 are basically broken for Linux. I
only started using 5.1 a few months ago. For me, this regression is
relatively new to my gdb.


H.J.

Re: gdb 5.2 removes the conditional breakpoints

[Eli Zaretskii]

On Thu, 18 Apr 2002, Michael Veksler wrote:

> Your argument that "5,2 has been around for ~4
> years" does not hold water, how many people have been using 5.2 ?

You misunderstood: Andrew said that between 4.17 and 5.2, all versions of 
GDB had this bug.  Those versions in between are in use for 4 years, not 
version 5.2 (which wasn't released yet).

> The "many
> eyeballs" effect takes place only when you "release early, release often"
> and 4 years cycle is anything but "often".

You misunderstood again: there were several versions of GDB during those 
4 years, not one version.

> Now that you have a branch, people will start using it. Bugs will be
> spotted, some of them will be critical (SEGV), some will be very bad (an
> important gdb state gets reset upon restart) and others will be simply
> annoying (print syntax will not work the way it is supposed to).

Bugs which have relatively safe fixes will be fixed on the branch.  Bugs 
that don't have safe fixes will have to wait for the next release.  New 
features (as opposed to bugfixes) will have to wait, period.

Please be aware of the downside of fixing everything indiscriminately: it 
means that GDB 5.2 will never be released, since ``there's always one 
more bug''.  So what will go into the branch and what won't is a 
judgement call, not something that is self-evident.

> second bug (few hours later), was this conditional breakpoint problem. This
> problem is very annoying in C++. Every condition with virtual functions
> gets removed (at least those that I tried).

Until it gets fixed, you can work around this problem by creating a .gdbinit 
file which sets all the breakpoints automatically.

Re: gdb 5.2 removes the conditional breakpoints

[Michael Veksler]

This is a real problem. Your argument that "5,2 has been around for ~4
years" does not hold water, how many people have been using 5.2 ? The "many
eyeballs" effect takes place only when you "release early, release often"
and 4 years cycle is anything but "often".

<rant>
Now that you have a branch, people will start using it. Bugs will be
spotted, some of them will be critical (SEGV), some will be very bad (an
important gdb state gets reset upon restart) and others will be simply
annoying (print syntax will not work the way it is supposed to). That's
life. If you want to make gdb better, you'd have to do things that the gcc
team does now:
1. Shorten development cycle (gcc's goal is 6 months, but ,
    they'll probably need 8)/
2. Fix regressions of a branch even if they have "been around for 4 years".
3. Fix bugs even if they are not yours (gcc-2.95.4 had a work-around for
    a glibc bug).

I started 5.2 evaluation only a month ago. The first bug I noticed was that
it crashed with SEGV every time (which I reported, and it got fixed). The
second bug (few hours later), was this conditional breakpoint problem. This
problem is very annoying in C++. Every condition with virtual functions
gets removed (at least those that I tried).

I did not report it, because I am only toying with migrating my code to
Linux and doing it in my spare time. My product is libraries, so it is my
responsibility to make sure my users/customers can debug the code. So if
they are about to run it on Linux, I have to make sure they can use gdb
comfortably. If important fixes (like this one) do not get applied, I'll
have to maintain a fork of gdb. I do not get paid to maintain Free SW (or
OSS), so I hate this option (my manager will probably hate this even more).
My users will hate this also (who wants to use forked code?)
</rant>

Please apply this patch to 5.2 branch (or at least say what's wrong with
the patch, so that it can be perfected, and applied).


   Michael


Andrew Cagney <ac131313@cygnus.com> on 18-04-2002 06:21:02

Please respond to Andrew Cagney <ac131313@cygnus.com>

To:    "H . J . Lu" <hjl@lucon.org>
cc:    Michael Veksler/Haifa/IBM@IBMIL, gdb@sources.redhat.com
Subject:    Re: gdb 5.2 removes the conditional breakpoints



> 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

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

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]

> 
> 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 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;

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 !!! ----


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