[Bug gdb/14789] New: stale thread slowdown
mathis.ahrens at gmx dot de
sourceware-bugzilla@sourceware.org
Wed Oct 31 05:15:00 GMT 2012
http://sourceware.org/bugzilla/show_bug.cgi?id=14789
Bug #: 14789
Summary: stale thread slowdown
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: gdb
AssignedTo: unassigned@sourceware.org
ReportedBy: mathis.ahrens@gmx.de
Classification: Unclassified
Created attachment 6712
--> http://sourceware.org/bugzilla/attachment.cgi?id=6712
test case
> I am trying to debug a multithreaded program with gdb but get unexpected side effects.
>
> Test case code is attached.
> Basically, main() is an endless loop that
> - creates two threads t1 & t2
> - joins t2
> - increments an iteration counter i.
> t2 shall wait until t1 exists, then cancel and join t1.
> t1 does nothing, but has a cleanup handler that increments a counter c.
>
> When running without gdb, the output is as expected:
> i=1, c=1, dt=0.000848
> i=1001, c=1001, dt=0.095550
> i=2001, c=2001, dt=0.081302
> i=3001, c=3001, dt=0.089316
> i=4001, c=4001, dt=0.088792
> i=5001, c=5001, dt=0.086609
> i=6001, c=6001, dt=0.086388
> i=7001, c=7001, dt=0.090560
> ...
>
> [ i: iteration, c: cancellation handler calls, dt: time ]
>
> When running inside gdb (4.5 and master), I get:
> i=1, c=1, dt=0.005421
> i=1001, c=1000, dt=2.675437
> i=2001, c=2000, dt=5.822094
> i=3001, c=3000, dt=9.502770
> i=4001, c=4000, dt=15.998418
> i=5001, c=4999, dt=30.724420
> i=6001, c=5999, dt=57.917127
> i=7001, c=6999, dt=109.575370
> i=8001, c=7999, dt=162.559419
> i=9001, c=8999, dt=187.046422
> ...
>
>
> First, c is not incremented for every iteration.
> Maybe gdb inserts a cancellation point before the cleanup handler gets pushed ? Is this expected behavior ?
>
> Second, the time per 1000 iterations increases rapidly.
> I cannot figure a reason for that. Do you see this too ?
>
> I am running this on ubuntu 12.04 64bit with eglibc-2.15 and gcc-4.6.3.
Thanks. I've tried this with current mainline, and I see the same.
I suspect that the issue is GDB's inferior thread list just keeps
growing, and linear walks over the list cost more and more.
If you ctrl-c, and do "info threads; c", you'll see dt= coming back
down, as that cleans up stale thread entries.
gprof seems to confirm it:
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
66.55 39.01 39.01 1323158 0.03 0.03 find_thread_ptid
9.35 44.49 5.48 85368 0.06 0.07 set_executing
6.07 48.05 3.56 3310723008 0.00 0.00 ptid_equal
3.89 50.33 2.28 42684 0.05 0.07 set_running
3.60 52.44 2.11 149391 0.01 0.03 iterate_over_threads
3.54 54.52 2.08 227719151 0.00 0.00
currently_stepping_or_nexting_callback
1.57 55.44 0.92 272137 0.00 0.00 ptid_get_tid
--
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.
More information about the Gdb-prs
mailing list