This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] malloc: Re-add protection for recursive calls to __malloc_fork_lock_parent
- From: "Tulio Magno Quites Machado Filho" <tuliom at linux dot vnet dot ibm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 11 May 2016 11:16:06 -0300
- Subject: Re: [PATCH] malloc: Re-add protection for recursive calls to __malloc_fork_lock_parent
- Authentication-results: sourceware.org; auth=none
- References: <57323BCE dot 3070305 at redhat dot com> <1462919631-30048-1-git-send-email-tuliom at linux dot vnet dot ibm dot com> <57332B05 dot 6020504 at redhat dot com>
Florian Weimer <email@example.com> writes:
> On 05/11/2016 12:33 AM, Tulio Magno Quites Machado Filho wrote:
>> I wonder if it requires a new bug report as 8a727af9 has been backported
>> to glibc 2.23.
> We already have a bug for this, I think:
Thanks for pointing that.
> I've just attached a more reliable test case to this bug. For me, it is
> quite reliable with even quite old glibcsâthe test case indicates
> delivery of a few signals and then goes into deadlock.
> I believe the new test is completely valid because sigusr1_handler calls
> only async-signal-safe functions (the old one should really call _exit
> instead of exit in the signal handler).
> I tried this test with current master and your patch applied on top, and
> I still get deadlocks. Can you give this test a try as well?
It did get into deadlock soon here.
> A true fix for bug 19703 depends on bug 19702 (Provide a flag indicating
> whether a thread is in a signal handler), which is not easy to address
> because we need an async-signal-safe sigaction/signal function and need
> to atomically change the signal handler and its associated flags.
Thanks for pointing that too!