__lll_mutex_lock_wait ()

[Mani]

Hi,
I am having an issue with a C++ application pegging CPU on a RedHat AS3.0
box. I did a gdb on the process and the trace is given below.

#0 0xb6f2c241 in __lll_mutex_lock_wait () from /lib/tls/libc.so.6
#1 0xb6eb7e64 in _L_mutex_lock_2507 () from /lib/tls/libc.so.6
#2 0x0820f5b0 in ?? ()
#3 0xafdcd538 in ?? ()
#4 0xb6e3c7fc in ?? () from /usr/lib/libstdc++.so.5
#5 0x0820f520 in ?? ()
#6 0x0820f5b0 in ?? ()
#7 0xafdcd538 in ?? ()
#8 0xb6e1a263 in operator delete () from /usr/lib/libstdc++.so.5

In the code I am doing a delete on a pointer. Don't know why should it hang
on some mutex? Also why should hang result in CPU being pegged.

Will be gateful to any help.

Thanks,
Mani.

 

[Thomas Maier-Komor]

Hi,
I am having an issue with a C++ application pegging CPU on a RedHat AS3.0
box. I did a gdb on the process and the trace is given below.

#0 0xb6f2c241 in __lll_mutex_lock_wait () from /lib/tls/libc.so.6
#1 0xb6eb7e64 in _L_mutex_lock_2507 () from /lib/tls/libc.so.6
#2 0x0820f5b0 in ?? ()
#3 0xafdcd538 in ?? ()
#4 0xb6e3c7fc in ?? () from /usr/lib/libstdc++.so.5
#5 0x0820f520 in ?? ()
#6 0x0820f5b0 in ?? ()
#7 0xafdcd538 in ?? ()
#8 0xb6e1a263 in operator delete () from /usr/lib/libstdc++.so.5

In the code I am doing a delete on a pointer. Don't know why should it hang
on some mutex? Also why should hang result in CPU being pegged.

Will be gateful to any help.

Thanks,
Mani.

looks like a corrupted heap as a result of a memory management
error. This is usually caused by calling delete on a single object
multiple times or by writing past the end of an allocated memory
block... I suggest using valgrind to find the offending lines of
code.

Tom

 

[Paul Pluzhnikov]

Mani wrote:

The most likely reason is that the heap mutex that free() is trying
to lock is corrupt.

The most likely reason for that is calling async-signal-unsafe
functions (such as malloc or printf) from a signal handler.

Does your app handle any signals?

looks like a corrupted heap as a result of a memory management
error.

No, it doesn't look anything like that.

I suggest using valgrind to find the offending lines of code.

This suggestion is still good though.

[This has nothing to do with comp.lang.c++. Follow-to set]

Cheers,