This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/14379] shared object constructors are called in the wrong order
- From: "luto at mit dot edu" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Tue, 24 Jul 2012 15:21:19 +0000
- Subject: [Bug dynamic-link/14379] shared object constructors are called in the wrong order
- Auto-submitted: auto-generated
- References: <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.