tree d934cdd4ad67a012359a4851c3faf37e6017a06e
parent 659a23b455dce45e9bf3ff291c7cbc214b7993d1
author Willy Tarreau <w@1wt.eu> 1657882138 +0200
committer Christopher Faulet <cfaulet@haproxy.com> 1701848840 +0100

BUG/MINOR: debug: enter ha_panic() only once

Some panic dumps are mangled or truncated due to the watchdog firing at
the same time on multiple threads and calling ha_panic() simultaneously.
What may happen in this case is that the second one waits for the first
one to finish but as soon as it's done the second one resets the buffer
and dumps again, sometimes resetting the first one's dump. Also the first
one's abort() may trigger while the second one is currently dumping,
resulting in a full dump followed by a truncated one, leading to
confusion. Sometimes some lines appear in the middle of a dump as well.
It doesn't happen often and is easier to trigger by causing massive
deadlocks.

There's no reason for the process to resist to a panic, so we can safely
add a counter and no nothing on subsequent calls. Ideally we'd wait there
forever but as this may happen inside a signal handler (e.g. watchdog),
it doesn't always work, so the easiest thing to do is to return so that
the thread is interrupted as soon as possible and brought to the debug
handler to be dumped.

This should be backported, at least to 2.6 and possibly to older versions
as well.

(cherry picked from commit 55433f9b344b430f3f8ec91106b9d8772168eafc)
 [ad: adjusted context.]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 853a6e20057d54dc0c23bb851a9b7ac15ca33a49)
[cf: In fact, it had to be backported to 2.4 too. Should fix #2331]
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>