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/14577] New: dlopen does not unload failed module - second dlopen succeeds


http://sourceware.org/bugzilla/show_bug.cgi?id=14577

             Bug #: 14577
           Summary: dlopen does not unload failed module - second dlopen
                    succeeds
           Product: glibc
           Version: 2.12
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
        AssignedTo: unassigned@sourceware.org
        ReportedBy: astrand@cendio.se
    Classification: Unclassified


We have a .so file that cannot be loaded on a certain machine, due to missing
dependencies. In this case, dlopen() correctly returns NULL. However, the
module stays in adress space, and a second dlopen() returns non-NULL. Trying to
call functions in the module, however, will result in a segfault. Here's a
short test program:

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

/* 
   build:

   gcc -Wall dlopen.c -ldl -o dlopen 

   run:

   LD_BIND_NOW=1 ./dlopen ./foo.so 
*/

int main(int argc, char **argv)
{
        void *lib;

        lib = dlopen(argv[1], RTLD_LAZY);
        fprintf(stderr, "Lib: %p\n", lib);

        lib = dlopen(argv[1], RTLD_LAZY);
        fprintf(stderr, "Lib: %p\n", lib);

        return 0;
}

Execution example:


$ LD_BIND_NOW=1 ./dlopen ./module-alsa-sink.so 
Lib: (nil)
Lib: 0x1295030

The .so file is admittedly bad since, but it seems strange the dlopen() should
report success the second time. 
Output from ldd:

$ ldd -r ./module-alsa-sink.so 
    linux-vdso.so.1 =>  (0x00007fff8ffff000)
    libpulsecore-UNKNOWN.UNKNOWN.so =>
/home/astrand/ctc/client/pulseaudio-new/src/.libs/libpulsecore-UNKNOWN.UNKNOWN.so
(0x00007f324db90000)
    libpulsecommon-UNKNOWN.UNKNOWN.so =>
/home/astrand/ctc/client/pulseaudio-new/src/.libs/libpulsecommon-UNKNOWN.UNKNOWN.so
(0x00007f324d8c2000)
    libpulse.so.0 =>
/home/astrand/ctc/client/pulseaudio-new/src/.libs/libpulse.so.0
(0x00007f324d665000)
    libalsa-util.so =>
/home/astrand/ctc/client/pulseaudio-new/src/.libs/libalsa-util.so
(0x00007f324d420000)
    libasound.so.2 => /lib64/libasound.so.2 (0x00007f324d120000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f324cf03000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f324ccfb000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f324caf6000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f324c872000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f324c4df000)
    /lib64/ld-linux-x86-64.so.2 (0x00000035ee800000)
symbol snd_pcm_hw_params_can_disable_period_wakeup, version ALSA_0.9 not
defined in file libasound.so.2 with link time reference   
(/home/astrand/ctc/client/pulseaudio-new/src/.libs/libalsa-util.so)
symbol snd_pcm_hw_params_set_period_wakeup, version ALSA_0.9 not defined in
file libasound.so.2 with link time reference   
(/home/astrand/ctc/client/pulseaudio-new/src/.libs/libalsa-util.so)
symbol snd_pcm_hw_params_get_period_wakeup, version ALSA_0.9 not defined in
file libasound.so.2 with link time reference   
(/home/astrand/ctc/client/pulseaudio-new/src/.libs/libalsa-util.so)

The system is a CentOS 6 x86_64 with all updates installed.

-- 
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]