This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Report dlsym, dlvsym lookup errors using dlerror [BZ #19509]
- From: Martin Sebor <msebor at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 09 Feb 2016 14:10:31 -0700
- Subject: Re: [PATCH] Report dlsym, dlvsym lookup errors using dlerror [BZ #19509]
- Authentication-results: sourceware.org; auth=none
- References: <56B9F83A dot 1000500 at redhat dot com>
On 02/09/2016 07:31 AM, Florian Weimer wrote:
I'm not sure if this is the right fix. I traced back the lack of error
reporting to the original addition of the RTLD_NEXT functionality. I
don't know why it was omitted from it.
I happened to come across the corresponding bug in Red Hat Bugzilla
and wanted to chime in on the patch.
POSIX requires dlerror() to return a non-null string after a dynamic
linking error. After a failed call to dlopen(), dlclose(), or dlsym(),
POSIX says that "More detailed diagnostic information shall be
available through dlerror()." dlerror() is required to return null
only when no error has occurred since the last call to the function,
or on failure. (It doesn't matter that RTLD_NEXT isn't fully
specified by POSIX.)
So AFAICS, the patch does the right thing. I would only suggest to
enhance the test to verify that dlerror() does return a null pointer
when no error has occurred (e.g., the second call to dlerror() with
no other intervening dlxxx() calls should return null).
If there isn't already a test in the test suite that exercises
the interaction of dladdr() and dlerrror() (I couldn't find one)
it would be worth adding one to verify that a failed dladdr()
doesn't affect dlerrror() (it doesn't seem to in my testing).
But that's probably outside of the scope of this bug fix.