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
_______________________________________________
Bug-libtool mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool
