Jeff Squyres wrote:
> Since this now has me intrigued :-), I downloaded glibc and had a look
> at dlerror(). I didn't follow it all the way through, but it looks
> like it *could* be erroneous to call dlerror() without first calling
> dlopen(). Here's some code right at the top of dlerror():
>
> -----
> /* Get error string. */
> result = (struct dl_action_result *) __libc_getspecific (key);
> if (result == NULL)
> result = &last_result;
>
> /* Test whether we already returned the string. */
> if (result->returned != 0)
> -----
>
> I *think* the __libc_getspecific() thing will return 0. So result
> will == NULL, and it'll use &last_result. And last_result does not
> appear to be statically initialized. So "result->returned" could well
> generate Badness.
>
> I'm not 100% sure that's happening, but I think it is...
I now have a copy of the glibc 2.2.5 source, too, and I have another
take on this.
The __libc_getspecific call tries to get thread-specific data, using
something called 'Hurd cthreads library'. It only returns 0, if it
can't get the data. So last_result is only used as a last resort, and
it may never get used.
Maybe that is the problem. Perhaps something in LAM is preventing the
other library from being linked or causing it to link incorrectly.
I'll try to build a -g version of libdl, so that I can step through the
dlerror call. I don't know how to do that, yet, but I'll try to get
some help.
--
Dick Hadsell 914-259-6320 Fax: 914-259-6499
Reply-to: hadsell_at_[hidden]
Blue Sky Studios http://www.blueskystudios.com
44 South Broadway, White Plains, NY 10601
|
