This is the mail archive of the gdb-patches@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]

Re: [patch] Fix deadlock on looped solib list


On Wed, 07 Apr 2010 21:47:09 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 
> Jan> While some simple n^2 check or maximal allowed libraries list could
> Jan> be more simple remembering Google was patching GDB for very large
> Jan> solib lists.
> 
> I don't remember hearing about this... anybody know why this isn't
> in the FSF GDB?

It should be checked-in:
	[rfc][patch] Eliminate quadratic slow-down on number of solibs.
	http://sourceware.org/ml/gdb-patches/2009-04/msg00548.html

It were multiple long threads across multiple months.


> Jan> gdb/
> Jan> 2010-04-03  Jan Kratochvil  <jan.kratochvil@redhat.com>
> Jan> 	Fix deadlock on looped list of loaded shared objects.
> Jan> 	* arch-utils.c (core_addr_hash, core_addr_eq): New.
> Jan> 	* arch-utils.h: Include hashtab.h.
> Jan> 	(core_addr_hash, core_addr_eq): New prototypes.
> Jan> 	* defs.h: Include hashtab.h.
> Jan> 	(make_cleanup_htab_delete): New prototype.
> Jan> 	* solib-svr4.c: Include arch-utils.h.
> Jan> 	(svr4_current_sos): New variables lm_obstack, lm_hash, outer_chain,
> Jan> 	initialize them, call outer_chain do_cleanups at the bottom.  Move new
> Jan> 	and old_chain initializations after a new duplicity check of LM using
> Jan> 	new variable lm_slot.
> Jan> 	* utils.c (do_htab_delete_cleanup, make_cleanup_htab_delete): New.
> 
> This is ok.  Thanks.

I have just found now Daniel J.'s (not checked in):
	[RFC] Detect loops in the solib chain
	http://sourceware.org/ml/gdb-patches/2008-07/msg00347.html

This hashtab approach of mine is needlessly expensive.

 * One should do next<->prev crosschecking suggested above.

 * To find the loop one cannot just look for the first element as it may loop
   one some tail elements.  One cannot find the last element as ... one could
   get looping trying to find it.  Updating the "first" element to the current
   one each 2^n steps (with increasing n) should safely find the loop.  And
   much cheaper in the common non-looping case (and at most 2x expensive in
   the looping case).

I will post the new patch.


Thanks,
Jan


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