bugGNU Octave - Bugs: bug #58678, Deadlock when deleting a figure...


bug #58678: Deadlock when deleting a figure while another figure is beingdeleted

Submitter:  Pantxo Diribarne <pantxo>
Submitted:  Mon 29 Jun 2020 08:27:19 PM UTC
Category:  Plotting with OpenGL Severity:  4 - Important
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


Wed 19 Aug 2020 08:46:04 PM UTC, comment #2: 

@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).

Pantxo Diribarne <pantxo>
Project Member
Wed 19 Aug 2020 04:34:21 PM UTC, comment #1: 

I can confirm that the deadlock still happens in current Octave 6.0.1 stable (hg id d075c2f26d1d).

It looks like it also deadlock in Octave 5.2.0 (on Windows). So this is not a regression.
That probably also means that we can lock (and unlock) recursively on Windows (which is a good thing iiuc).

Should this block the release in that case? (I'd guess it shouldn't.)

Markus M├╝tzel <mmuetzel>
Project Member
Mon 29 Jun 2020 08:27:19 PM UTC, original submission:  

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

Pantxo Diribarne <pantxo>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by pantxo (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-08-19 mmuetzel Operating SystemGNU/Linux Any

    Back to the top

    Powered by Savane 3.9