From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: When I start my application, it keeps waiting in a mutex call. The call stack I get when I used gdb is as follows : #0 0xb75ebc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7485c76 in __lll_mutex_lock_wait () from /lib/tls/libc.so.6 #2 0x080538e0 in ?? () #3 0xb74d1d98 in __DTOR_END__ () from /lib/tls/libc.so.6 #4 0x08053930 in ?? () #5 0xb73fd551 in _L_mutex_lock_42 () from /lib/tls/libc.so.6 Version-Release number of selected component (if applicable): How reproducible: Couldn't Reproduce Actual Results: Application deadlocks. Expected Results: Application should start up. Additional info: Please refer to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102682.
It can't be #102682, because #102682 has been fixed before RHEL3 has been released. Without the source of your application we can't find out what's going on. Additionally, it is much more likely this is an application bug rather than a glibc bug. We are not going to debug your own code just because it might be also a glibc bug. You need to debug your application yourself (e.g. see on which mutex/condvar it deadlocks, analyze the use of that synchronization primitive as well as all others that are somehow related to it) and only when you create a (small) self-contained testcase that proves the bug is in fact in glibc, file a bug. There is absolutely nothing we can do for you from the above backtrace.
Thanks for the repsonse. I shall try to create a testcase for the same.