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

Submitted by:  CarnĂ« Draug <carandraug>
Submitted on:  Wed 08 Apr 2015 04:46:35 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: NoneAssigned to: None
Originator Name: Open/Closed: Open
Release: 4.0.0Operating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

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>
Project 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>
Project Member
Fri 17 Apr 2015 06:54:06 PM UTC, comment #2:

Adding jwe to the CC list for the bug.

Rik <rik5>
Project 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:

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

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):

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>
Project Member
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:

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:

if index does not use "end":

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

Carnë Draug <carandraug>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by rik5
  • -unavailable- added by goffioul (Posted a comment)
  • -unavailable- added by carandraug (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 02 Jun 2015 04:41:26 PM UTCjweRelease4.0.0-rc2=>4.0.0
    Fri 17 Apr 2015 06:54:06 PM UTCrik5Carbon-Copy-=>Added jwe

    Back to the top


    Powered by Savane 3.1-cleanup1