This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] malloc: Re-add protection for recursive calls to __malloc_fork_lock_parent

On 05/11/2016 12:33 AM, Tulio Magno Quites Machado Filho wrote:
I've just understood what you meant by "this could have happened
before".  I do agree it was already broken.  It was just too difficult
to reproduce it here.

With commit ID 8a727af9, I get:
     $ x=0; while ./ ./malloc/tst-mallocfork  ; do x=$((x + 1)); \
     done; echo $? $x
     Timed out: killed the child process
     0 10

After applying this patch, it runs for hours without failing.  But it
clearly doesn't fix it.
However, if you believe the test case is invalid, let's remove it.

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:

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?

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.

I think I can provide a partial fix for single-threaded programs without bug 19702. It's going to be rather small but quite ugly.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]