Bug 166049

Summary:	Kernel 2.4.21-4.ELsmp on an i686
Product:	Red Hat Enterprise Linux 3	Reporter:	Anand <anand_mirasdar>
Component:	glibc	Assignee:	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 10:05:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Anand 2005-08-16 09:43:54 UTC

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 10:05:07 UTC

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 10:16:32 UTC

Thanks for the repsonse. I shall try to create a testcase for the same.