Re: glibc 2.19 deadlock in asprintf

[Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>]

On 22 May 2014 16:08, Arkadiusz MiÅkiewicz <arekm@maven.pl> wrote:
> On Thursday 22 of May 2014, Siddhesh Poyarekar wrote:
>> That's a backtrace of just one thread - please get a backtrace of all
>> threads in play using 'thread apply all backtrace'.  There isn't
>> enough information to conclude that this is a bug, but I am going to
>> guess that it is not, and that there may have been either some kind of
>> memory corruption or a malloc call from a signal handler causing a
>> deadlock.
>
> There are no other threads. It's preforked apache.

The hung lock you see is acquired whenever a malloc (or calloc,
realloc, free, I'm using malloc as a catch-all name here) call wants
to synchronize access to an arena.  The only case where this would
hang is if a previous malloc call acquired the lock but failed to free
it.  That would usually happen if the current malloc was called within
a signal handler, which was called in the middle of a malloc call.
However, there is no signal handler here, so the other possibility
could be that of a malloc call being unwound before it was completed
by, say, a longjmp (via a signal handler?), again resulting in a stale
lock.

I would make sure that none of these is true and then look at the
possibility of this being a glibc bug.  There are no known bugs that
look like this and all cases I have come across that look like this
usually end up exposing some kind of weird undefined behaviour in the
application.

Siddhesh
-- 
http://siddhesh.in