bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] Dangling Pointer in libltdl


From: Ralf Wildenhues
Subject: Re: [patch] Dangling Pointer in libltdl
Date: Tue, 23 Jan 2007 20:46:36 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Dave,

Thanks for the bug report.

* Dave Brolley wrote on Thu, Jan 18, 2007 at 07:39:23PM CET:
> 
> The attached patch fixes a problem with a dangling pointer in lt_dlexit 
> withing libltdl. The problem is that lt_dlclose  is recursively called 
> (via unload_deplibs) in order to close dependent libraries. One of these 
> might be (and was for me!) the one pointed to by 'cur'.

I have trouble reproducing this bug easily.  Which system does it happen
on?  How does the graph formed by modules/libraries and
interdependencies (linking against/dlopening) look like?  In what order
are things opened/linked against, which ones are closed explicitly, for
this to trigger?  Do you mix calls to lt_dlopen with direct calls to
dlopen?  Do you mix libraries created with libtool with libraries
created without?

I would like to apply a test case along with the fix.  Easiest for me
would be to see a small example reproducing this (if you need help, I
can post an unfinished test case for this), or, failing that, the
original code that exposes the bug.  Failing that, you could put up an
strace output of a program that exposes the bug.  That way we should
hopefully be able to infer most information.  But be sure to bzip2-pack
it if you must post it rather than putting it on some web page.

> @@ -283,10 +283,19 @@ lt_dlexit (void)
>                       {
>                         ++errors;
>                       }
>                   }
>               }
> +           /* Make sure that the handle pointed to by 'cur' still exists.
> +              lt_dlclose recursively closes dependent libraries which removes
> +              them from the linked list.  One of these might be the one
> +              pointed to by 'cur'.  */
> +           for (tmp = handles; tmp; tmp = tmp->next)
> +             if (tmp == cur)
> +               break;
> +           if (! tmp)
> +             cur = handles;

If the description is correct, the whole addition could go in the true
branch of the `if (tmp->info.ref_count <= level)' test, no?

Cheers, and thanks again,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]