__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]

Post by 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.

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]

Post by Thomas Maier-Komor

Post by Mani
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

...

Post by Thomas Maier-Komor

Post by Mani
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.

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?

Post by Thomas Maier-Komor
looks like a corrupted heap as a result of a memory management
error.

No, it doesn't look anything like that.

Post by Thomas Maier-Komor
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,

[Mani]

It is a multi threaded program which handles signal. But what I am surprised
is it is not happening in the signal handler. It is inside another function.
I have std::map with pointer variables and erase the map and delete the
pointer.

Another thing that I don't understand is will lock_wait results in CPU
pegging.

Thanks for your help.

Post by Paul Pluzhnikov

Post by Thomas Maier-Komor

Post by Mani
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

...

Post by Thomas Maier-Komor

Post by Mani
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.

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?

Post by Thomas Maier-Komor
looks like a corrupted heap as a result of a memory management
error.

No, it doesn't look anything like that.

Post by Thomas Maier-Komor
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,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[Paul Pluzhnikov]

"Mani" <***@cisco.com> writes:

A. Because doing so makes the conversation harder to read.
Q. Why should I not top-post?

Please do not top post. Rest of the message re-ordered.

Post by Mani

Post by Paul Pluzhnikov
Does your app handle any signals?

It is a multi threaded program which handles signal. But what I am surprised
is it is not happening in the signal handler.

What's likely happening in your signal handler is the corruption
of the mutex. You observe the effect of that corruption later.

Post by Mani
Another thing that I don't understand is will lock_wait results in CPU
pegging.

Once you've corrupted a mutex, your program behaviour is undefined.
It can crash, hang or spin in the CPU, or it may even appear to work,
only to crash/hang/spin on the next system you try it on.

Cheers,