[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bugs blocking the 6.1 release

From: John W. Eaton
Subject: Bugs blocking the 6.1 release
Date: Wed, 13 May 2020 14:18:39 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

We have three bugs tagged as blockers for the 6.1 release:

  * GUI hangs on use of uiputfile
    (Apparently MacOS only?

  * Segmentation faults with clang when running the test suite
    (Intermittent failure that happens only with Clang?)

  * handles to private functions may fail after "clear functions"
    (Also revealed many function handle issues.)

I'm not sure what to do about the first two but I've been working on function handle issues related to the third one. I have a series of pending changes that you can see here:


Here's a summary with additional commentary not included in the commit messages. By far, the largest change is the most recent one:

  * 64b7dedbc220
    wip: refactor octave_fcn_handle class

Split the octave_fcn_handle class internally into several sub-classes for the following types of function handles:

      - simple
      - scopedfunction
      - nested
      - classsimple
      - anonymous

These changes and others leading up to this point were initially motivated by bug #57439 (handles to private functions may fail after "clear functions"). Investigating that bug revealed many more issues with function handles. A rewrite seemed like a better long-term solution than simply fixing symptoms.

This change is still a work in progress. The most important remaining task is to make saving and loading handles work for all types of handles and file types (text, binary, hdf5, and mat5) but this has a lower priority for me than making handles themselves work properly.

Other related changes leading up to this one are, in reverse chronological order:

  * 4c35fd270522
    try harder to find functions in some symbol_table find_* functions

If a function names is not already in the cache of known functions, add it to the list and search again. Some search functions already worked this way, so this change makes the behavior more consistent.

  * c2a7460d1900
    new functions for finding scoped functions and class methods

Moving these searches into separate functions helps to make changeset 64b7dedbc220 (wip: refactor octave_fcn_handle class) simpler.

  * 7d3280c8373b
    move make_fcn_handle to tree_evaluator class

The make_fcn_handle function belongs in the evaluator. This helps to make changeset 64b7dedbc220 (wip: refactor octave_fcn_handle class) simpler.

  * a40c4af1c73d
    refactor handling of parent functions and localfunctions

    A step toward proper scopedfunction function handles.

  * e8b8f7ea102c
    new cellstring constructor

    Trivial change that helps with implementing changeset a40c4af1c73d.

  * 4c3873bf7b9a
store local init vars for anonymous functions in handle, not function object

As with nested functions, the local variables associated with anonymous functions should be stored in the function handle instead of the function referenced by the handle.

  * 61fbce0b302b
    refactor octave_function call method

This change is a step toward storing stack frames associated with handles to nested functions in the function handle instead of the function referenced by the handle.

  * 45227dd1dbb3
    don't document the vectorize function.

Use of this function is discouraged. It has limited usefulness, even for the obsolete @inline class.

  * a90e8d0da19d
    convert obsolete octave_fcn_inline object to @inline class

Use of @inline objects is discouraged and should be replaced by anonymous functions. Moving @inline into an M-file legacy class instead of deriving it from the internal function handle object makes it easier to remove later, and simplifies refactoring the internal function handle object.

  * 6900f86908af
use shared_ptr for stack frames in call stack and for accesss and static links

This makes it easy for us to grab references to subsets of stack frames that are used to access values of non-local symbols in nested functions. Having shared access to these stack frames is necessary to properly implement handles to nested functions.

  * f959268bca07
    hide specific stack frame and stack frame walker classes

The specific stack frame classes are not needed explicitly so it seems better to only manipulate them through the generic interface to the stack_frame object. This is a fairly minor change.

Another change that will eventually be needed is to modify function handles to hold a weak_ptr reference to the actual function object. That way, handles that are used after functions are cleared can noticed that the function was cleared an properly attempt to reload them. Ultimately, this change is the one that will correctly fix the bug that motivated all of these other changes(!). But until that is done, at least Octave won't fail and the performance issue that Philip noticed on Windows systems will be minimized.

I've been working on stable with the idea that these changes could be applied to stable and included in the release. I know that this is a big set of changes to push at the last minute, but it seems best to me to make handles to nested functions actually work properly since that was one of the big changes that was supposed to happen in version 6.

A big positive from these changes is that the function handle implementation is much clearer and more reliable than it was before as well as being more compatible with Matlab behavior. The way function calls are performed has also improved.

This is a lot of information to digest in one message, so we can break the discussion up in pieces if needed. Either way, I welcome any comments.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]