Bug 132553
Summary: | All threads are waiting for mutex libc_free, non of them are obtaining it | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 2.1 | Reporter: | Murat Berk <murat_berk> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 2.1 | CC: | drepper, fweimer |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-08-18 09:31:51 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
Murat Berk
2004-09-14 18:34:44 UTC
There really isn't any information in the report which can help solving the issue. And I don't know about any other reports like this. My guess is that there has been previously a memory corruption of some sort of a malloc function has been used incorrectly (called from a signal handler, double free, ...). Did you run your program code using a memory handling debugger? Either with some of the simple-minded once like dmalloc and EFence which come with RHEL. Or valgrind on RHEL4? Also, can this be reproduced on RHEL3 or RHEL4? Without a self-contained testcase I think we can't move with this. If you create a reproducer, please reopen with the attachment. Hi, Though I cannot give you any self-contained testcase, but I also see exactly same problem on 2.4.9-e.34enterprise #1 SMP Wed Dec 10 16:42:39 i686 I see this problem in following senario - I do a longjmp from within a signal handler (SIGALRM) and it takes quite long for the jump to actualy happen. The stack trace always shows pthread_mutex_lock wait (as reported in this bug) in libc_free routine. thanks, ravi Hi, I might have incorrectly stated the problem above as I have seen so many different cases in last 2 weeks. is it possible that following could be happening - 1. When I call longjmp, a mutex is left unclosed by libc_free (Note in this mode, I am not using threads in my application) 2. Longjump happens and when I try and cleanUp stuff after this, free finds a mutex and just waits for someone to open it for it. Another problem that I saw while using threads was that after I issue pthread_cancel, I do a pthread_join on the canceled thread (or else I run into libc mutex problem cited above) and then join takes forever - in one case it took almost 2500s of real time. thanks, ravi |