Menu
First of all sorry for calling malloc inside signal handler :).I too understand we should not do any time consuming task/this kind of nasty stuff inside signal handler.
But i am curious to know the reason why it is crashed ?
#0 0x00006e3ff2b60dce in _lll_lock_wait_private () from /lib64/libc.so.6
#1 0x00006e3ff2aec138 in _L_lock_9164 () from /lib64/libc.so.6
#2 0x00006e3ff2ae9a32 in malloc () from /lib64/libc.so.6
#3 0x00006e3ff1f691ad in ?? () from ..
i got similar core reported in https://access.redhat.com/solutions/48701 .
operating system : RHEL
625
A single threaded malloc wouldn't be async signal safe either unless explicitly designed to be so which is hard. In fact anything that touches mutable state, including thread local state is a problem.
Signal Handlers. A signal handler is special function (defined in the software program code and registered with the kernel) that gets executed when a particular signal arrives. This causes the interruption of current executing process and all the current registers are also saved.
There are several methods of delivering signals to a program or script. One of the most common is for a user to type CONTROL-C or the INTERRUPT key while a script is executing. When you press the Ctrl+C key, a SIGINT is sent to the script and as per defined default action script terminates.
A Default signal handler is associated with every signal that the kernel runs when handling that signal. The action that a script or program performs when it receives a signal is called the default actions. A default signal handler handles these types of different default actions.
malloc() is not a function that can be safely called from a signal handler. It's not a async-signal-safe function.
So, you should never call malloc() from a signal handler. You are only allowed to call a limited set of functons from a signal handler.
See the man signal-safety for the list of functions you can safely call from a signal handler.
Looking at your GDB output, it appears that while malloc() is holding a lock, you are calling malloc() again which results in a deadlock.
67
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
