performance of multithreading gets gradually worse under gdb
Ulrich Weigand
uweigand@de.ibm.com
Thu Feb 3 21:40:00 GMT 2011
Tom Tromey wrote:
> >>>>> "Markus" == Markus Alber <markus@hyperion-imrt.org> writes:
>
> Markus> See the attached file. It shows a similar behaviour, although it only
> Markus> allocates 8kB per iteration.
> Markus> You have to wait some time before this happens.
>
> Thanks.
>
> I changed 1<<24 to 1<<15, to spare my underpowered machine, and ran gdb
> under massif.
>
> This part is interesting:
>
> ->20.78% (2,954,016B) 0x8253683: regcache_xmalloc_1 (regcache.c:232)
> | ->20.78% (2,954,016B) 0x8253F85: get_thread_arch_regcache (regcache.c:463)
> | ->20.78% (2,954,016B) 0x82540B5: get_thread_regcache (regcache.c:488)
> | ->20.78% (2,954,016B) 0x81D1579: i386_linux_resume (i386-linux-nat.c:861)
> | | ->20.78% (2,954,016B) 0x81D7D32: linux_nat_resume (linux-nat.c:1983)
>
>
> I debugged gdb a little and it does indeed seem to be leaking here.
>
> I don't understand why registers_changed_ptid unconditionally clears
> current_regcache. I suspect that may be the source of the problem.
>
> Perhaps someone who knows this code better could take a look.
It seems this leak was introduced by Pedro's patch here:
http://sourceware.org/ml/gdb-patches/2010-04/msg00960.html
The function used to free all regcaches in the list and then
reset current_regcache. The new code now takes care to selectively
free only a subset of regcaches -- and then resets current_regcache
anyway ...
I guess we should just remove the current_regcache = NULL line now.
(Actually, now that every thread always has a thread_info, the
best thing would probably be anyway to hang each thread's regcaches
off the thread_info, and do away with the global list completely.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
More information about the Gdb
mailing list