This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/14379] shared object constructors are called in the wrong order


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]