At 12:31 AM 12/4/00 EST, you wrote:
>I'm getting similar crashes with a non-SMP kernel in a non-SMP machine.
>only 32m with 70m swap, however.
>
>Maybe dlopen is reentrant by being serialized with a critical section or
>so, but it doesn't like being made to recurse. Yes, I think we have a
>problem.
I know you trust the code, not the comments, but here was the
intention of ppl writing this part of glibc :
/* During the program run we must not modify the global data of
loaded shared object simultanously in two threads. Therefore we
protect `_dl_open' and `_dl_close' in dl-close.c.
This must be a recursive lock since the initializer function of
the loaded object might as well require a call to this function.
At this time it is not anymore a problem to modify the tables. */
__libc_lock_define_initialized_recursive (, _dl_load_lock)
I am fighting with a dlopen crashing problem since the beginning of the
new dll loading mechanism, of course :-). It happens for me with
Eudora Light 3.06, Turnpike 5.02 and Acrobat Reader 3.01 (although
the crash does not appear at the same place with Acrobat). I don't
have any Smp machine.
I am mostly in the dark, and unsure if my problem is the same
as you and the rest (maybe there are *several* problems). The only
think I am sure of is that with Eudora, my problem does *not* occur
on a small test computer I have setup using RedHat 7.0. I intend to look
at the differences in the code between these libc versions.
Gerard
