Thu 21 Sep 2017 02:26:34 PM UTC, comment #3:
In an unwind_protect object, I don't think there is a way to know if the pointer to a variable is pointing to a freed heap memory or not. If I am not wrong on that point, it is not safe to use unwind_protect objects to restore variables that we can't be sure will still be allocated at restore time.
I attached a tentative patch that calls for criticism since (i) I am not sure it is good practice to cast pointers to int, (ii) I don't know how to check things still work as expected, i.e. a callback can't be executed recursively.
(file #41854)
|
Tue 19 Sep 2017 06:12:21 PM UTC, comment #1:
The issue is still not completely understood, but for a new FLTK figure the function _add_default_menu_.m is called. This creates the uimenu object for the figure. One of the menu entries is File->Close and the associated callback is the pure piece of Octave code "close (gcf)".
The issue seems to be that FLTK detects the menu click, and then the uimenu object attempts to run the callback code in an unwind/protect block. The callback code closes the figure which deletes the uimenu object. When control returns from the callback, the unwind protect block now has a non-existent uimenu object. That's all I can tell so far. I don't have a good way of solving this just yet.
|
Thu 14 Sep 2017 07:59:25 PM UTC, original submission:
Creating a figure and then closing it with "File->Close" creates a use-after-free error. If the figure is closed from the command line using "close" then there is no such problem.
Sample code:
The backtrace is
|