bugGNU Octave - Bugs: bug #54369, [MXE-Octave] crash on...


bug #54369: [MXE-Octave] crash on "__octave_link_gui_preference__"

Submitted by:  Markus Mützel <mmuetzel>
Submitted on:  Tue 24 Jul 2018 10:24:43 PM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  Torsten Lilge <ttl>
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Microsoft Windows

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Fri 27 Jul 2018 12:02:55 PM UTC, comment #4:

Thanks for the quick fix. I tested on Windows 10 and it also no longer segfaults for me.

Closing as fixed.

Markus Mützel <mmuetzel>
Project Member
Thu 26 Jul 2018 06:21:10 PM UTC, comment #3:

I have pushed cset
wchih fixes the bug on windows 8 for me.

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Wed 25 Jul 2018 06:38:58 PM UTC, comment #2:

Markus, thanks for debugging.

I stumbled about the same sentence in the docs. The unlock was to make sure that the lock is really unlocked, a habit I have taken some time ago while programming for a certain real-time operation system. I am currently thinking about just dropping this unlock or using the mutex that already exists in octave_qt_link (knowing this mechanism works).

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Wed 25 Jul 2018 06:29:30 PM UTC, comment #1:

With debug symbols, I get the following backtrace:

That means it segfault on the unlock here:

I don't know why it is tried to unlock the thread before it is locked in the next line. And locked again (?) with the next command.
The Qt manual for "unlock" [1] reads: "Unlocking a mutex that is not locked results in undefined behavior."
So we should probably try and avoid that.

[1]: http://doc.qt.io/qt-5/qmutex.html

Markus Mützel <mmuetzel>
Project Member
Tue 24 Jul 2018 10:24:43 PM UTC, original submission:

With a Windows cross-build of a recent tip (hg id 4de7535ece11), I get a segmentation fault on the following command:

Attaching to gdb gives the following traceback:

Assigning to Torsten since he recently added this function.
Can I do anything to help debugging? Should I recompile with symbols to get a more verbose backtrace? (Might take a while)

Markus Mützel <mmuetzel>
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 ttl (Posted a comment)
  • -email is unavailable- added by mmuetzel (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-27 mmuetzel StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2018-07-26 ttl StatusNone => Ready For Test

    Back to the top

    Powered by Savane 3.4