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 Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool