public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bug_rh at spam dot wizbit.be" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/15378] New: Segmentation fault when LD_LIBRARY_PATH contains (only) non-existings paths Date: Thu, 18 Apr 2013 15:00:00 -0000 [thread overview] Message-ID: <bug-15378-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=15378 Bug #: 15378 Summary: Segmentation fault when LD_LIBRARY_PATH contains (only) non-existings paths Product: glibc Version: 2.17 Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: unassigned@sourceware.org ReportedBy: bug_rh@spam.wizbit.be CC: drepper.fsp@gmail.com Classification: Unclassified Created attachment 6989 --> http://sourceware.org/bugzilla/attachment.cgi?id=6989 Patch to add 'env_path_list' exception We get a segmentation fault when LD_LIBRARY_PATH contains only non-existings paths. The segfault seems to happen only in combination with RPATH but we're not 100% sure if that is the only way to trigger this... Test code that triggers it: $ cat foo1.c int foo1_lib1 = 5; $ cat foo2.c extern int foo1_lib1; int foo2_lib2 = 6; void func() { foo2_lib2 = foo1_lib1; } $ cat a.c #include <stdio.h> #include <unistd.h> #include <dlfcn.h> int main () { printf("A\n"); sleep(5); printf("B\n"); dlopen("/tmp/glibc/libfoo2.so", RTLD_LAZY); printf("C\n"); } $ cc -fPIC -o foo1.o -c foo1.c $ cc -fPIC -Wl,-rpath=/usr/lib -shared -Wl,-soname,libfoo1.so -o libfoo1.so foo1.o $ cc -fPIC -o foo2.o -c foo2.c $ cc -fPIC -Wl,-rpath=/usr/lib -L . -shared -Wl,-soname,libfoo2.so -o libfoo2.so foo2.o -l foo1 Now check that libfoo2.so is linked with libfoo1.so: $ ldd libfoo2.so ... libfoo1.so => not found ... Check the path of libdb.so. On my system this is /usr/lib/libdb.so.2 => use -rpath=/usr/lib in the following commands. If 'libdb.so' is located in another directory then the path in the following commands need to be changed: $ cc -o a.out a.c -ldl $ cc -Wl,-rpath=/usr/lib -o a_rpath.out a.c -ldl $ cc -Wl,-rpath=/usr/lib,--enable-new-dtags -o a_rpath_runpath.out a.c -ldl Running it: $ LD_LIBRARY_PATH=/non_existing_path ./a.out # => no segfault $ LD_LIBRARY_PATH=/non_existing_path ./a_rpath.out # => segfault $ LD_LIBRARY_PATH=/non_existing_path ./a_rpath_runpath.out # => no segfault Note: this does not apperr to be reproducible on all systems... * Testing this on a custom build system using glibc-2.7 shows the segfault on 'a_rpath.out' * Testing this on a custom build system using glibc-2.13 shows the segfault on 'a_rpath.out' * Testing this on a custom build system using glibc-2.17 shows the segfault on 'a_rpath.out' * Testing this on Ubuntu 8.04 using glibc-2.7 shows no segfault on ''a_rpath.out' (no idea why) * Testing this on Ubunutu 12.10 using glibc-2.15 shows the segfault on 'a_rpath.out' Backtracing the segfault on glibc-2.17: Core was generated by `./a_rpath.out'. Program terminated with signal 11, Segmentation fault. #0 open_path (name=name@entry=0xb756a28e "libfoo1.so", namelen=namelen@entry=11, secure=secure@entry=0, sps=sps@entry=0xb770df24 <env_path_list>, realname=realname@entry=0xbffdf714, fbp=fbp@entry=0xbffdf71c, loader=0x9049028, whatcode=whatcode@entry=2, found_other_class=found_other_class@entry=0xbffdf713) at dl-load.c:2062 2062 sps->dirs = (void *) -1; (gdb) bt #0 open_path (name=name@entry=0xb756a28e "libfoo1.so", namelen=namelen@entry=11, secure=secure@entry=0, sps=sps@entry=0xb770df24 <env_path_list>, realname=realname@entry=0xbffdf714, fbp=fbp@entry=0xbffdf71c, loader=0x9049028, whatcode=whatcode@entry=2, found_other_class=found_other_class@entry=0xbffdf713) at dl-load.c:2062 #1 0xb76f507c in _dl_map_object (loader=0x9049028, name=<optimized out>, type=2, trace_mode=trace_mode@entry=0, mode=mode@entry=-2147483648, nsid=nsid@entry=0) at dl-load.c:2202 #2 0xb76f9998 in openaux (a=0xbffdfb08) at dl-deps.c:63 #3 0xb756b5d8 in __JCR_LIST__ () from /tmp/glibc/libfoo2.so #4 0xb76f9950 in ?? () at dl-deps.c:84 from /ub/lib/ld-linux.so.2 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Looking in the code: if (sps != &rtld_search_dirs) sps->dirs = (void *) -1; It fails on the assignment. Printing 'sps', 'rtld_search_dirs', 'env_path_list' shows: (gdb) print sps $1 = (struct r_search_path_struct *) 0xb770df24 <env_path_list> (gdb) print & rtld_search_dirs $2 = (struct r_search_path_struct *) 0xb770df1c <rtld_search_dirs> (gdb) print & env_path_list $3 = (struct r_search_path_struct *) 0xb770df24 <env_path_list> => 'sps' is not equal to 'rtld_search_dirs' but 'sps' is equal to 'env_path_list'. env_path_list is defined as: static struct r_search_path_struct env_path_list attribute_relro; => it is set as 'attribute_relro' Looking in the commit history shows: commit 392a6b52656c1bb40305375b0ea9020455044f9d author Ulrich Drepper <drepper@redhat.com> Thu, 15 Jan 2004 06:38:27 +0000 (06:38 +0000) => this commit added the 'attribute_relro' on 'env_path_list' and on 'rtld_search_dirs' commit ecc1d0c301d97bdd540ff8d414a2eb4dcae51ea0 author Ulrich Drepper <drepper@redhat.com> Mon, 7 Feb 2005 23:52:23 +0000 (23:52 +0000) => this commit added the exception for updating 'sps->dirs' We believe an exception for 'env_path_list' is also needed. A patch for this is attached. -- 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-04-18 15:00 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-04-18 15:00 bug_rh at spam dot wizbit.be [this message] 2013-05-17 13:36 ` [Bug libc/15378] " siddhesh at redhat dot com 2013-09-21 19:51 ` neleai at seznam dot cz 2014-02-07 3:22 ` [Bug dynamic-link/15378] " jsm28 at gcc dot gnu.org 2014-06-13 18:25 ` fweimer at redhat dot com 2014-10-12 23:11 ` hong at topbug dot net 2014-10-12 23:47 ` allan at archlinux dot org 2015-01-25 5:42 ` allan at archlinux dot org
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-15378-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).