At 03:59 PM 12/4/00 -0500, you wrote:
>I think I've found the problem. It seems to be a bug in glibc 2.1.2.
>If a dlopen() call fails, it sets an internal variable to point to a
>string describing the error (for later retrieval with dlerror()). If
>you then call dlopen() again, without calling dlerror() in between to
>clear the error status, dlopen() will free the string. Then it tries to
>load the library, and sets the internal variable again depending on
>whether the open succeeded or failed. However, during the time that its
>trying to load the library, it keeps this internal variable pointing to
>a now-freed block of memory. As we call dlopen() again before the
>loading of the library finishes, it tries to free the same memory twice.
Great ! you have found it. Thanks a bunch.
The following patch to glibc 2.1.3 fixes all my failures : Eudora 3.06, Turnpike 5.01,
Acrobat 3.
--- dlerror.c.orig Sun Aug 1 23:55:05 1999
+++ dlerror.c Tue Dec 5 15:35:31 2000
@@ -121,7 +121,8 @@
/* Free the error string from the last failed command. This can
happen if `dlerror' was not run after an error was found. */
free (result->errstring);
-
+ result->errstring = NULL;
+
result->errcode = _dl_catch_error (&result->errstring, operate, args);
/* If no error we mark that no error string is available. */
>Short of forcing everyone to upgrade to glibc 2.2
Everyone should be able to patch the glibc, no ? ;-)
> we can work around this issue in Wine.
<snip>
>Thoughts?
IIRC glibc 2.1.3 is the basis for the Linux compatibility project, dubbed
LSB or LSD, I don't remember. It's a good opportunity to give it the kiss of
death if it's still needed :-)
>(BTW, inserting a dlerror() call right before
> if (!ret) ret = dlopen( buffer + dll_path_maxlen + 1, RTLD_NOW );
>in library/loader.c hacks around the problem for me for now).
This direct hack is not working for me, but patching the glibc works fine.
Big thanks again.
Gerard
