From 447062a6999c2df9cd35d6c4297dc1a55bd39cd7 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sun, 28 Jun 2020 00:40:04 +0200 Subject: [PATCH] fatal-signal: Make multithread-safe. * lib/fatal-signal.c (at_fatal_signal): Don't free the old actions array. --- ChangeLog | 5 +++++ lib/fatal-signal.c | 7 +++++++ 2 files changed, 12 insertions(+) diff --git a/ChangeLog b/ChangeLog index 7e046bc402..12dadaaa36 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2020-06-27 Bruno Haible + + fatal-signal: Make multithread-safe. + * lib/fatal-signal.c (at_fatal_signal): Don't free the old actions array. + 2020-06-27 Bruno Haible clean-temp: Don't force deletion of temporary files on native Windows. diff --git a/lib/fatal-signal.c b/lib/fatal-signal.c index 975393b4a0..c6f8dacbde 100644 --- a/lib/fatal-signal.c +++ b/lib/fatal-signal.c @@ -239,8 +239,15 @@ at_fatal_signal (action_t action) actions = new_actions; actions_allocated = new_actions_allocated; /* Now we can free the old actions array. */ + /* No, we can't do that. If fatal_signal_handler is running in a + different thread and has already fetched the actions pointer (getting + old_actions) but not yet accessed its n-th element, that thread may + crash when accessing an element of the already freed old_actions + array. */ + #if 0 if (old_actions != static_actions) free (old_actions); + #endif } /* The two uses of 'volatile' in the types above (and ISO C 99 section 5.1.2.3.(5)) ensure that we increment the actions_count only after -- 2.39.5