changeset:   32995:7f47ba772a19
branch:      stable
parent:      32992:88bff22985bd
user:        Markus Mützel <markus.muetzel@gmx.de>
date:        Fri Feb 09 18:33:49 2024 +0100
summary:     filter: Add small tolerance to BIST with floating point input.

Attached thread sanitizer trace. Not sure how useful it could be.

Dmitri.
--



(file #55682)

This still deadlocks in Octave 9.0.90 with the following commands:

hf = figure ();
hf2 = figure ();
addlistener (hf, "beingdeleted", @(h,e) delete (hf2));
delete (hf);

@Markus: This possible deadlock has been present for one release cycle now and had not been reported yet. It looks like those recursive patterns are not very likely to happen, so I'd also vote for making this a high priority but not a blocker.

>> That probably also means that we can lock (and unlock) recursively on Windows (which is a good thing iiuc).

Yes this means that linux and windows implementations are consistent (and both different from what I had expected when I introduced this bug).

Here is a robust way to deadlock with Octave 5.1, stable and default:

hf = figure ();
hf2 = figure ();
addlistener (hf, "beingdeleted", @() delete (hf2));
delete (hf);

I dug into this and it turns out that this sequence provokes a recursive call to F__go_delete__. This function uses an octave::autolock to lock the graphics mutex and then unlock it at return. When graphics_toolkit::finalize is called, the graphics mutex has been locked twice and using gh_manager::unlock is not enough to unlock it (unlocking twice avoids the deadlock).

IOW, I just discovered that octave_mutex is a recursive mutex, and there is no way to unlock it unless you know the number of times it has been previously locked in the same thread. See also [1] for a discussion about recursive mutexes.

So both qt_graphics_toolkit::initialize and finalize, can possibly deadlock.

PS: Contrary to what I have said in [2], our implementation of mutex is thus very well suited for recursive use with octave::autolock.

PPS: I tagged this bug as segfault since a deadlock looks as critical.
 
[1] http://www.zaval.org/resources/library/butenhof1.html
[2] https://octave.1599824.n4.nabble.com/segfaults-in-graphics-code-likely-threading-issues-td4697518.html