public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "luto at mit dot edu" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug dynamic-link/14379] shared object constructors are called in the wrong order Date: Tue, 24 Jul 2012 15:21:00 -0000 [thread overview] Message-ID: <bug-14379-131-YOXq9Lay2g@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-14379-131@http.sourceware.org/bugzilla/> http://sourceware.org/bugzilla/show_bug.cgi?id=14379 --- Comment #2 from Andy Lutomirski <luto at mit dot edu> 2012-07-24 15:21:19 UTC --- Here's a silly malloc replacement library: #include <sys/mman.h> #include <stdlib.h> static char *arena; __attribute__((constructor)) static void init() { arena = (char*)mmap(0, 1 << 24, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); } void *malloc(size_t n) { void *ret = arena; arena += n; return ret; } void *realloc(void *ptr, size_t size) { abort(); } void free(void *p) {} IMO it should work (as long as no one tries to use realloc, calloc, or threads, but this is just an example). Here's a rather ordinary shared library: #include <malloc.h> __attribute__((constructor)) static void init() { *(char*)malloc(1) = 0; } This is, of course, silly, but in C++, dynamic allocation due to global object constructors is common. If I try to use that library with the malloc replacement LD_PRELOADed, it crashes: 19797: calling init: /lib64/ld-linux-x86-64.so.2 19797: 19797: 19797: calling init: /lib64/libc.so.6 19797: 19797: 19797: calling init: /lib64/libgcc_s.so.1 19797: 19797: 19797: calling init: /lib64/libm.so.6 19797: 19797: 19797: calling init: /lib64/libstdc++.so.6 19797: 19797: 19797: calling init: ./test_lib.so 19797: Segmentation fault The malloc library (silly_malloc.so in this case) wasn't initialized. I think that, in any sensible initialization order, LD_PRELOADed libraries would initialize first, not last. (Maybe libraries in the DT_NEEDED list of the LD_PRELOADed library should initialize even sooner, but that's irrelevant here.) My comment about initializing deeper dependencies first is something that current glibc does right. I don't think that should change. -- 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 prev parent reply other threads:[~2012-07-24 15:21 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-20 19:12 [Bug dynamic-link/14379] New: " luto at mit dot edu 2012-07-21 16:29 ` [Bug dynamic-link/14379] " ppluzhnikov at google dot com 2012-07-24 1:41 ` carlos_odonell at mentor dot com 2012-07-24 15:21 ` luto at mit dot edu [this message] 2012-09-11 23:41 ` luto at mit dot edu 2012-09-12 2:11 ` carlos_odonell at mentor dot com 2012-12-04 0:00 ` carlos at systemhalted dot org 2014-06-17 18:57 ` fweimer at redhat dot com 2014-10-02 16:43 ` luto at mit dot edu 2014-10-02 16:45 ` luto at mit dot edu 2014-10-02 16:46 ` luto at mit dot edu 2022-08-29 9:46 ` [Bug dynamic-link/14379] shared object constructors are called in the wrong order (with interposition) 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-14379-131-YOXq9Lay2g@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /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).