Bug 166049

Summary: Kernel 2.4.21-4.ELsmp on an i686
Product: Red Hat Enterprise Linux 3 Reporter: Anand <anand_mirasdar>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: Application deadlocks forever..i have to kill it
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-16 06:05:07 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Anand 2005-08-16 05:43:54 EDT
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.
Comment 1 Jakub Jelinek 2005-08-16 06:05:07 EDT
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.
Comment 2 Anand 2005-08-16 06:16:32 EDT
Thanks for the repsonse. I shall try to create a testcase for the same.