bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

dlload twice with the same library (after dlclose) with static executabl


From: Matthias Weise
Subject: dlload twice with the same library (after dlclose) with static executable
Date: Wed, 13 Aug 2003 10:28:08 +0200
User-agent: KMail/1.5.2

Hi,

I have the following problem: I am using glibc Version 2.2.5 (Linux) 
and get a segmentation fault everytime I load the same library with 
dlload a second time after a dlclose from a statically linked 
executable. You can reproduce that very easily with the following 
small program.

#include <stdio.h>
#include <dlfcn.h>

int main (int argc, char *argv[])
{
  void *handle;

  if (argc > 1) {
    handle = dlopen (argv[1], RTLD_NOW);
    if (handle == NULL) {
      printf("%s\n", dlerror());
      return -1;
    }
    dlclose (handle);

    handle = dlopen (argv[1], RTLD_NOW);
    if (handle == NULL) {
      printf("%s\n", dlerror());
      return -1;
    }
    dlclose (handle);
  }
  return 0;
}

I compile it with the following 

gcc testNormalize.c -static -o testNormalize -ldl 

and it crashes with a segmentation fault. I tested selfmade libraries 
and system libraries and found no exception up to now. If I use a 
debug glibc (libc, libdl) and run the executable in the gdb, it shows 
the following trace (it also crashes in the same method if you 
compile without debug symbols) :

#0  0x08062eaa in do_lookup_versioned (undef_name=0x40003925 
"_LIB_VERSION", hash=216508030, ref=0x400024e8, result=0xbffff698, 
scope=0x0, i=0, version=0x80bcb00, skip=0x0,
    type_class=0) at do-lookup.h:52
#1  0x080625a8 in _dl_lookup_versioned_symbol (undef_name=0x40003925 
"_LIB_VERSION", undef_map=0x80bc260, ref=0xbffff728, 
symbol_scope=0x80bc3a4, version=0x80bcb00,
    type_class=0, explicit=0) at dl-lookup.c:396
#2  0x080816ff in elf_machine_rel.0 () at 
../sysdeps/i386/dl-machine.h:368
#3  0x08081861 in elf_dynamic_do_rel.4 () at do-rel.h:100
#4  0x080819da in _dl_relocate_object (l=0x80bc260, scope=0x80bc3a4, 
lazy=0, consider_profiling=0) at dl-reloc.c:155
#5  0x0806415f in dl_open_worker (a=0xbffff960) at dl-open.c:294
#6  0x0806360e in _dl_catch_error (objname=0xbffff958, 
errstring=0xbffff95c, operate=0x8063d24 <dl_open_worker>, 
args=0xbffff960) at dl-error.c:152
#7  0x08064277 in _dl_open (file=0xbffffc9f "libm.so.6", 
mode=-2147483646, caller=0x80482b4) at dl-open.c:411
#8  0x0804833c in dlopen_doit (a=0xbffffad0) at dlopen.c:39
#9  0x0806360e in _dl_catch_error (objname=0x80bc1c8, 
errstring=0x80bc1cc, operate=0x8048318 <dlopen_doit>, 
args=0xbffffad0) at dl-error.c:152
#10 0x08048560 in _dlerror_run (operate=0x8048318 <dlopen_doit>, 
args=0xbffffad0) at dlerror.c:130
#11 0x08048369 in __dlopen_check (file=0x0, mode=0) at dlopen.c:53
#12 0x080482b4 in main (argc=2, argv=0xbffffb74) at testNormalize.c:21

It crashes because in line 52 the local variable list is a NULL 
pointer and is accessed via the []-operator. This local variable is 
set by scope->r_list where scope is a parameter of the 
do_lookup_versioned call. 
I am using Debian Woody distribution with kernel version 2.4.20 and 
gcc 3.2.3

And so my question is: Do I do something wrong ? Did I miss some 
guidelines for using dlopen/dlclose ? Is it a bug and if yes is it 
fixed in later version.

Thanks for your help in advance

        Best regards

                Matthias Weise





reply via email to

[Prev in Thread] Current Thread [Next in Thread]