This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
[dthorpe@inprise.com] libc/1854: dlopen() segfaults on some module filenames returned by dladdr
- To: libc-alpha Mailinglist <libc-alpha at sourceware dot cygnus dot com>
- Subject: [dthorpe@inprise.com] libc/1854: dlopen() segfaults on some module filenames returned by dladdr
- From: Andreas Jaeger <aj at suse dot de>
- Date: 09 Aug 2000 16:15:54 +0200
- Cc: dthorpe at inprise dot com
Hi libc developers,
we've received the appended bug report. Could somebody please check
it?
Thanks,
Andreas
Subject: Topics
Topics:
libc/1854: dlopen() segfaults on some module filenames returned by dladdr()
- To: bugs at gnu dot org
- Subject: libc/1854: dlopen() segfaults on some module filenames returned by dladdr()
- From: dthorpe at inprise dot com
- Date: Tue, 8 Aug 2000 19:37:33 -0400
>Number: 1854
>Category: libc
>Synopsis: dlopen() segfaults on some module filenames returned by dladdr()
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: libc-gnats
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Aug 08 19:40:01 EDT 2000
>Last-Modified:
>Originator: dthorpe@inprise.com
>Organization:
net
>Release: 2.1.91
>Environment:
RedHat 7 beta / Pentium III Dell box
>Description:
In 2.1.91, dladdr() appears to have been updated to return success when the given address is in the address range of the main program. dladdr() now returns the name of the main executable in the info structure and result of success.
However, dlopen() segfaults when given the module filename returned by dladdr() when the module is the main program (not a shared object). It looks like dlopen() doesn't realize that the module filename is the main executable, and it tries to map it into memory (again), which fails badly.
With dladdr() returning 1 for both shared objects and main program queries, there is no way to distinguish between the two to make dlopen() work!
If dlopen() can't be fixed to work reliably with the filename returned by dladdr(), please fix dladdr() to return a different value (2?) for the main program case.
On a separate note, dladdr() uses dl_argv[0] to fetch the module file name. Is this reliable? I've been told arv[0] depends on how the shell chooses to set up the environment for the process, and can't be relied upon across shells.
>How-To-Repeat:
call dladdr(&main, dlinfo) <<< returns 1
call dlopen(dlinfo.dli_fname, RTLD_NOW) <<< segfault
>Fix:
>Audit-Trail:
>Unformatted:
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj