public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "macro@linux-mips.org" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/15022] New: Global-scope dlopen issues in static executables Date: Wed, 16 Jan 2013 22:40:00 -0000 [thread overview] Message-ID: <bug-15022-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=15022 Bug #: 15022 Summary: Global-scope dlopen issues in static executables Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: dynamic-link AssignedTo: unassigned@sourceware.org ReportedBy: macro@linux-mips.org Classification: Unclassified We have two issues with dlopen [1] issued from static executables when the global scope is accessed. First, an attempt to add a dynamic shared module to the global scope (i.e. with RTLD_GLOBAL requested) crashes like this: Program received signal SIGSEGV, Segmentation fault. add_to_global (new=0x49ef60) at dl-open.c:101 101 ns->_ns_global_scope_alloc This is because at this point in static executables no global search list data structure has been initialised and as result the _ns_main_searchlist member of _dl_ns[LM_ID_BASE] (the initial namespace) is null. Second, an attempt to access the global scope itself (i.e. by using a null file name pointer) fails with an obscure error like: /path/to/dir/: cannot read file data: Is a directory (that can be retrieved with dlerror), where /path/to/dir/ is the first directory searched according to the dynamic load engine's shared module lookup policy. This is because the null file name pointer is internally converted to an empty string, that is in turn looked for and then opened in the directories examined. Of course that succeeds -- the directory itself is opened, but then the engine gets confused by the outcome and bails out. The use of an empty string works in dynamic executables, because for them the dynamic loader has already prepared a link map referring to a file whose name is empty -- which, by means of how that code works, is the executable itself -- and that makes the loader abandon any file look-ups and use the link map already present. The two issues both boil down to the same bug -- no global scope present. Patch offered: http://sourceware.org/ml/libc-alpha/2013-01/msg00635.html [1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/dlopen.html -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next reply other threads:[~2013-01-16 22:40 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-16 22:40 macro@linux-mips.org [this message] 2013-06-28 15:33 ` [Bug dynamic-link/15022] " macro@linux-mips.org 2014-01-31 18:03 ` cvs-commit at gcc dot gnu.org 2014-06-13 19:02 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-15022-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).