This is the mail archive of the gdb-prs@sourceware.org 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]

[Bug threads/13251] frequent multithreading slows down GDB to theextent of making it unusable


http://sourceware.org/bugzilla/show_bug.cgi?id=13251

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #1 from Tom Tromey <tromey at redhat dot com> 2011-11-09 20:36:21 UTC ---
(In reply to comment #0)
> This is a follow-up on a bug that was submitted by me in Feb 2011 and never
> resolved fully. I waited for 7.3 and it is still there.

Which PR is this?

> The problem: the application program spawns a great many threads (in the
> thousands, altogether) which each lives for a few ms. The threads are started
> by boost::thread.
> 
> Each thread seems to allocate some memory in gdb which is never freed fully.
> Further, the gdb process does something on a single CPU which grows longer in
> time the more threads have been started (and stopped). With the growing
> overhead
> on a single CPU, performance drops rapidly. In the end, the process grinds to 
> a halt, with GDB using all of one CPUÂs capacity.

I wrote a simple program that has a loop creating and joining short-lived
(1 second) threads.  I ran this for quite some time but didn't see any
performance degradation or memory increase.

Do you have, or can you construct, a test case we can use?
The fewer dependencies the better.

What platform are you on?  I am using x86-64 Fedora 15.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


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