This is the mail archive of the libc-help@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]

RE: Glibc 2.5 - dlsym issue in threaded app.


Guys, any news here?

-----

Hello list,

[I'm not subscribed so pls CC me]

Here is my problem.
We migrating our app from 2.4 kernel and glibc2.3.2 to 2.6 kernel and glibc 2.5 - latest CentOS5.2.
We using some memory wrappers for malloc, calloc, etc. I was able to reproduce the problem on the following small app:

---------------------------------------------------------------

Fri Oct 31 17:26:24
[vivanov@galatea MEMORY_WRAP]$ cat main_nothreads.c
#define _GNU_SOURCE

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

void * calloc(size_t n, size_t sz)
{
    printf("start\n");

    void *ptr;
    void *(*real_malloc)(size_t, size_t);
    real_malloc = (void *(*)(size_t, size_t))dlsym(RTLD_NEXT, "calloc");
    ptr = (*real_malloc)(n, sz);

    printf("end\n");
    return ptr;
}

int main(int argc, char *argv[])
{
    void* mem = calloc(2, 20);
    printf ("%p\n", mem);

    return 0;
}

Fri Oct 31 17:26:29
[vivanov@galatea MEMORY_WRAP]$ gcc -ldl main_nothreads.c
Fri Oct 31 17:26:46
[vivanov@galatea MEMORY_WRAP]$ ./a.out
start
end
0x9bb0008
Fri Oct 31 17:26:49
[vivanov@galatea MEMORY_WRAP]$ gcc -ldl -lpthread main_nothreads.c

---------------------------------------------------------------

This time app. Will fail. Here is back trace from debugger:

---------------------------------------------------------------
[New Thread -1208293696 (LWP 766)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208293696 (LWP 766)]
0x0078b8ec in _IO_new_file_write () from /lib/libc.so.6
(gdb) bt
#0  0x0078b8ec in _IO_new_file_write () from /lib/libc.so.6
#1  0x0078b5b5 in new_do_write () from /lib/libc.so.6
#2  0x0078b89f in _IO_new_do_write () from /lib/libc.so.6
#3  0x0078c1a8 in _IO_new_file_overflow () from /lib/libc.so.6
#4  0x0078eb33 in __overflow () from /lib/libc.so.6
#5  0x00782b9b in puts () from /lib/libc.so.6
#6  0x08048476 in calloc ()
#7  0x0089833c in _dlerror_run () from /lib/libdl.so.2
#8  0x00897d93 in dlsym () from /lib/libdl.so.2
#9  0x0804848a in calloc ()
#10 0x0089833c in _dlerror_run () from /lib/libdl.so.2
#11 0x00897d93 in dlsym () from /lib/libdl.so.2
#12 0x0804848a in calloc ()
#13 0x0089833c in _dlerror_run () from /lib/libdl.so.2
#14 0x00897d93 in dlsym () from /lib/libdl.so.2
#15 0x0804848a in calloc ()
#16 0x0089833c in _dlerror_run () from /lib/libdl.so.2
#17 0x00897d93 in dlsym () from /lib/libdl.so.2
#18 0x0804848a in calloc ()
#19 0x0089833c in _dlerror_run () from /lib/libdl.so.2
#20 0x00897d93 in dlsym () from /lib/libdl.so.2
#21 0x0804848a in calloc ()
---------------------------------------------------------------

So, what I understand is that dlsym when linked with pthreads is calling changed calloc and we enter infinite loop.
When we are not linking with pthreads is seems like dlsym doesn't call calloc at all.

Are you aware of this? What is the practice to avoid this endless loop?

Let me know if you need more info from me.

TIA,
V.


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