Bug 9335 - gdb does not handle a large number of breakpoints gracefully
Summary: gdb does not handle a large number of breakpoints gracefully
Alias: None
Product: gdb
Classification: Unclassified
Component: breakpoints (show other bugs)
Version: 6.6
: P3 enhancement
Target Milestone: 7.1
Assignee: Jan Kratochvil
Depends on:
Reported: 2007-02-18 00:48 UTC by tneuman
Modified: 2010-02-04 19:35 UTC (History)
3 users (show)

See Also:
Last reconfirmed:

gdbtestcase (171 bytes, application/octet-stream)
, tneuman

Note You need to log in before you can comment on or make changes to this bug.
Description tneuman 2007-02-18 00:48:01 UTC
[Converted from Gnats 2230]

When setting a large number of breakpoints, breakpoint handling slows down considerably. For example, when setting 50000 breakpoints (via a program, all by "tbreak *addr" with unique addresses), the first 10000 breakpoints are set reasonably fast (about 10s), but the whole 50000 breakpoints take about 8m. Probably a data structure does not scale.

While I noticed it for generated breakpoints on addressses, in occurs on more traditional breakpoints, too. See "How-To-Repeat" for an example.

GNU gdb 6.6

Linux jaiman 2.6.17-11-generic #2 SMP Thu Feb 1 18:03:05 UTC 2007 x86_64 GNU/Linux
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
This GDB was configured as "x86_64-unknown-linux-gnu".

Execute the following script (also attached):

echo 'int main() { int a=0;' > foo.c
for line in `seq 1 50000` ; do echo '++a;' ; done >> foo.c
echo '}' >> foo.c
gcc -o foo -g -O0 foo.c
echo 'set height 100000' > breakpoints
for line in `seq 1 50000` ; do echo tbreak foo.c:$line ; done >> breakpoints
time gdb foo -batch -x breakpoints

It tries to set 50000 different breakpoints, which takes quite a while.
Comment 1 tneumann 2007-02-18 23:21:56 UTC
From: Thomas Neumann <tneumann@users.sourceforge.net>
To: gdb-gnats@sources.redhat.com
Subject: Re: breakpoints/2230: gdb does not handle a large number of breakpoints
Date: Mon, 19 Feb 2007 00:21:56 +0100

 The slowdown is primarily caused by bp_location_chain in
 gdb/breakpoint.c. It consists of a linear list of all breakpoins, which
 is scanned for duplicates for each new breakpoint.
 Experimentally changing it from a list to a splay tree (organized by
 address) reduces the runtime for the test case from 8 minutes to 2
 minutes. Not exactly instantaneous, but much better. Now the hot spot is
Comment 2 Tom Tromey 2009-01-06 17:29:55 UTC
Your patch sounds worthwhile to me.
If you still have it, would you consider submitting it?
Here's some info on how to submit:


Comment 3 tneumann 2009-01-06 18:58:55 UTC
Subject: Re:  gdb does not handle a large number of
 breakpoints gracefully

I fear I lost it at some point in the last two years... But I think the
change was simple, I just rused some functions from libiberty.

Should I try to re-construct the patch? I have a copyright assignment
in place for gcc, but not for gdb, it might be simpler for you to just
implement it yourself. The patch was really small, if you grep for
bp_location_chain you see that it is only used in 7 places.
Comment 4 Jan Kratochvil 2009-09-05 17:19:35 UTC
Comment 5 Tom Tromey 2010-02-04 19:35:16 UTC
This was checked in a while ago.