Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 166049 - Kernel 2.4.21-4.ELsmp on an i686
Kernel 2.4.21-4.ELsmp on an i686
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Application deadlocks forever..i have...
Depends On:
  Show dependency treegraph
Reported: 2005-08-16 05:43 EDT by Anand
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-16 06:05:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.