Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Fix deadlock on looped solib list
Date: Wed, 07 Apr 2010 22:24:00 -0000	[thread overview]
Message-ID: <20100407222411.GA2253@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <m3y6gzujsy.fsf@fleche.redhat.com>

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


  reply	other threads:[~2010-04-07 22:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-03  9:23 Jan Kratochvil
2010-04-07 19:47 ` Tom Tromey
2010-04-07 22:24   ` Jan Kratochvil [this message]
2010-04-07 22:39     ` Tom Tromey
2010-04-09 15:42       ` [cancel] " Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100407222411.GA2253@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox