bugGNU Octave - Bugs: bug #44779, copy-on-write, varargin, and...


bug #44779: copy-on-write, varargin, and classdef: invalid dimension inquiry of a non-existent value

Submitter:  CarnĂ« Draug <carandraug>
Submitted:  Wed 08 Apr 2015 04:46:35 PM UTC
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Fri 14 Dec 2018 04:55:52 PM UTC, comment #5: 

Fixed somewhere along the way.  The original motivating example in comment #0 now runs.

Rik <rik5>
Group administrator
Tue 02 Jun 2015 04:41:26 PM UTC, comment #4: 

Retagging release from 4.0.0-rc2 to 4.0.0.

John W. Eaton <jwe>
Group administrator
Fri 17 Apr 2015 07:08:19 PM UTC, comment #3: 

I did some more experiments a few days ago, and it appears the fact that the magic "end" is propagated from E2 to E1 is to support expressions like:


I didn't know you could use "end" in a functional expression with the "end" being applied to the outer object. Googling a bit I found this ( http://stackoverflow.com/questions/23016606/what-are-the-semantics-of-end-in-matlab ), which implies this is an undocumented feature.

Michael Goffioul <goffioul>
Fri 17 Apr 2015 06:54:06 PM UTC, comment #2: 

Adding jwe to the CC list for the bug.

Rik <rik5>
Group administrator
Thu 09 Apr 2015 01:24:39 AM UTC, comment #1: 

I had a look at this one, hoping it would be trivial, but it's not. I know what is happening, but I'm not sure how to solve it. jwe's input will probably be needed.

The parser transforms this line:

p.parse (varargin{2:end})

into a parse tree structure using tree_index_expression (let's call it E1) with the following type and arguments:

. => "parse"
( => tree_index_expression representing "varargin{2:end}" (let's call it E2)

When E1 is executed, the code in tree_index_expression::rvalue will split the execution of the full indexed expression and first only execute the "." part. This is because the code detects there's a magic "end", so it needs to execute the index until (but not including) the magic "end", in order to apply this magic "end" on the right value. There's a comment in that code that claims it is related to handling expressions like "x{end}.a(end)", to process the second "end" correctly, but this doesn't seem to be our case and I believe the comment has just gone out of sync with the actual code.

What's happening is that because of the partial execution of the index expression, the code ends up calling "subsref" on the object "p" with the following arguments (note that it only contains the "." part):

. => "parse"

This is interpreted by the classdef code as being "p.parse()", that is calling the method "parse" without any argument (indeed, "p.parse" and "p.parse()" yields the same result for a method, for compatibility with Matlab). The method "inputParser.parse" does not return anything, so the result is an invalid object. This invalid object becomes the new current value being worked on by the index expression and the code quickly choke on the fact that it's undefined.

[jwe, if you could comment on the following, that'd be great]

At the core of the problem is the fact that E1 detects that is has a magic "end". IMO the expression E1 does not have a magic "end". The magic "end" applies to E2, not E1. Because of that, E1 tries to split the execution of its index, while it shouldn't try to. In other words, should tree_index_expression::has_magic_end really returns true when one of its argument's has_magic_end returns true?

Michael Goffioul <goffioul>
Wed 08 Apr 2015 04:46:35 PM UTC, original submission:  

First, apologies for the cryptic bug title but I just have no idea from where it comes from. Here's how to duplicate it:

function foobar (varargin)
  p = inputParser ();
  p.addParamValue ("foo", "bar", @ischar);
  p.parse (varargin{2:end});
octave-gui:2> foobar ([], "foo", "qux")
error: invalid dimension inquiry of a non-existent value
error: called from
    foobar at line 4 column 3

Note that the end does not happen inside inputParse, I have checked by debug printing, and it's not a statement at inputParser::parse that's throwing the error.

I'm not sure this is completely a classdef bug because it won't be triggered if varargin is copied into a new variable:

function foobar (varargin)
  p = inputParser ();
  p.addParamValue ("foo", "bar", @ischar);
  args = varargin(2:end);
  p.parse (args{:});
octave-gui:2> foobar ([], "foo", "qux")

if index does not use "end":

function foobar (varargin)
  p = inputParser ();
  p.addParamValue ("foo", "bar", @ischar);
  p.parse (varargin{2:3})
octave-gui:2> foobar ([], "foo", "qux")

or if simply using ":" to parse all of varargin:

octave-gui:1> function foobar (varargin)
  p = inputParser ();
  p.addParamValue ("foo", "bar", @ischar);
  p.parse (varargin{:})
octave-gui:2> foobar("foo", "qux")

Carnë Draug <carandraug>
Group 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 jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by carandraug (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 group members can vote.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-14 rik5 StatusNone Fixed
        Open/ClosedOpen Closed
    2015-06-02 jwe Release4.0.0-rc2 4.0.0
    2015-04-17 rik5 Carbon-Copy- Added jwe

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code