bugGNU Octave - Bugs: bug #59847, Unexpected behavior of evalin in...

 
 

bug #59847: Unexpected behavior of evalin in some cases

Submitter:  Torsten Lilge <ttl>
Submitted:  Fri 08 Jan 2021 08:18:10 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 6.1.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 22 Aug 2021 10:30:51 PM UTC, comment #15: 

zef

Anonymous
Thu 04 Feb 2021 05:11:51 PM UTC, comment #14: 

Tested on stable and this works for me.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Thu 04 Feb 2021 04:31:12 PM UTC, comment #13: 

I pushed the following change on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/6f6b5f2e5d4d

Marking as ready for test.

John W. Eaton <jwe>
Group administrator
Thu 04 Feb 2021 03:16:55 AM UTC, comment #12: 

I agree, it is also a change in an interface that wouldn't be widely used anyway.

But it turns out that maybe we don't need to change the interface anyway.  Here's another much simpler patch that also appears to solve the problem and just changes the internals of one function in the call_stack class.

If this looks OK, then I'll try to add a test and push to stable.

(file #50835)

John W. Eaton <jwe>
Group administrator
Wed 03 Feb 2021 09:51:11 PM UTC, comment #11: 

I wouldn't mind breaking API compatibility with 6.1.0.  Reasoning: 1) this is a regression and it is more important to return to the correct behavior then it is to preserve continuity; 2) Version 6.1.0 came out recently (~2 months ago) and is not widely, widely installed.  Thus, the number of users who need to upgrade is smaller than it might otherwise be; 3) Is this really going to hit very many people?  How many users are already coding C++ that relies on the existing API?

Rik <rik5>
Group administrator
Wed 03 Feb 2021 09:33:49 PM UTC, comment #10: 

Maybe a possible temporary way to avoid the API change would be to have each create function ask the call stack for the current frame.  But that means that each time a new frame is pushed on the call stack.  One way would be to add


  call_stack& cs = __get_call_stack__ ("...");
  m_caller = cs.current_frame ();


in the stack_frame constructor.  Or, since there can currently be only one interpreter/evaluator/call stack object, we could probably cache the call_stack object in a static variable the stack_frame class.

Or we could just break backward binary compatibility for this release.

Thoughts?

John W. Eaton <jwe>
Group administrator
Wed 03 Feb 2021 09:21:55 PM UTC, comment #9: 

I'm attaching a patch that appears to fix the problem for me.  I'm not sure how to make this change without an API change in the stack_frame class.

(file #50833)

John W. Eaton <jwe>
Group administrator
Wed 13 Jan 2021 08:08:30 AM UTC, comment #8: 

Thanks.  So the behavior for dbup appears to me to be the same in Octave and Matlab when it is used from a function called from the debug prompt.  But I guess the "caller" behavior for evalin will need to be handled differently.  I'll see if I can fix that.

John W. Eaton <jwe>
Group administrator
Wed 13 Jan 2021 07:40:33 AM UTC, comment #7: 

In Matlab R2020b:

>> f3

f3var =

     3


f2var =

     2


f1var =

     0

at the debug prompt, execute the commands:
  dbstack
  dbup
  dbstack
  who
  f0
K>> dbstack
> In f1 (line 11)
In f2 (line 3)
In f3 (line 3)
K>> dbup
In workspace belonging to f2 (line 3)
K>> dbstack
In f1 (line 11)
> In f2 (line 3)
In f3 (line 3)
K>> who

Your variables are:

f2var

K>> f0

f0var =

     0

at the following debug prompt, execute the commands:
  dbstack
  dbup
  dbstack
  who
  dbquit all
K>> dbstack
> In f0 (line 11)
In f1 (line 11)
In f2 (line 3)
In f3 (line 3)
K>> dbup
In workspace belonging to f1 (line 11)
K>> dbstack
In f0 (line 11)
> In f1 (line 11)
In f2 (line 3)
In f3 (line 3)
K>> who

Your variables are:

f1var

K>> dbquit all
>>


Markus Mützel <mmuetzel>
Group administrator
Tue 12 Jan 2021 06:03:40 PM UTC, comment #6: 

Oops, I forgot to attach the file again.  The one attached and linked in this comment is the one for comment #5.


(file #50709)

John W. Eaton <jwe>
Group administrator
Tue 12 Jan 2021 05:59:44 PM UTC, comment #5: 

Octave currently uses the equivalent of "dbup" to move to the "caller" workspace.  Since these are related issues, could someone please perform an additional test using the functions in the attached file?  After unpacking the tar.gz file, you'll have a directory called dbup-test.  Start Matlab in that directory and call the function "f3", then follow the displayed instructions and report the output of all the commands during the session.  Octave shows the following output:


octave:1> f3
f3var = 3
f2var = 2
f1var = 0
at the debug prompt, execute the commands:

  dbstack
  dbup
  dbstack
  who
  f0

stopped in f1 at line 11 [/net/devnull/scratch/jwe/build/octave/dbup-test/f1.m]
11:   keyboard
keyboard> dbstack
stopped in:

  --> f1 at line 11 [/net/devnull/scratch/jwe/build/octave/dbup-test/f1.m]
      f2 at line 3 [/net/devnull/scratch/jwe/build/octave/dbup-test/f2.m]
      f3 at line 3 [/net/devnull/scratch/jwe/build/octave/dbup-test/f3.m]
keyboard> dbup
stopped in f2 at line 3 [/net/devnull/scratch/jwe/build/octave/dbup-test/f2.m]
keyboard> dbstack
stopped in:

      f1 at line 11 [/net/devnull/scratch/jwe/build/octave/dbup-test/f1.m]
  --> f2 at line 3 [/net/devnull/scratch/jwe/build/octave/dbup-test/f2.m]
      f3 at line 3 [/net/devnull/scratch/jwe/build/octave/dbup-test/f3.m]
keyboard> who
Variables visible from the current scope:

f2var

keyboard> f0
f0var = 0
at the following debug prompt, execute the commands:

  dbstack
  dbup
  dbstack
  who
  dbquit all

stopped in f0 at line 11 [/net/devnull/scratch/jwe/build/octave/dbup-test/f0.m]
11:   keyboard
[1]keyboard> dbstack
stopped in:

  --> f0 at line 11 [/net/devnull/scratch/jwe/build/octave/dbup-test/f0.m]
      f1 at line 11 [/net/devnull/scratch/jwe/build/octave/dbup-test/f1.m]
      f2 at line 3 [/net/devnull/scratch/jwe/build/octave/dbup-test/f2.m]
      f3 at line 3 [/net/devnull/scratch/jwe/build/octave/dbup-test/f3.m]
[1]keyboard> dbup
stopped in f1 at line 11 [/net/devnull/scratch/jwe/build/octave/dbup-test/f1.m]
[1]keyboard> dbstack
stopped in:

      f0 at line 11 [/net/devnull/scratch/jwe/build/octave/dbup-test/f0.m]
  --> f1 at line 11 [/net/devnull/scratch/jwe/build/octave/dbup-test/f1.m]
      f2 at line 3 [/net/devnull/scratch/jwe/build/octave/dbup-test/f2.m]
      f3 at line 3 [/net/devnull/scratch/jwe/build/octave/dbup-test/f3.m]
[1]keyboard> who
Variables visible from the current scope:

f1var

[1]keyboard> dbquit all
octave:2>


John W. Eaton <jwe>
Group administrator
Tue 12 Jan 2021 07:21:01 AM UTC, comment #4: 

In Matlab R2020b:

>> f3

f3var =

     3


f2var =

     2


f1var =

     0

> In f1 (line 3)
In f2 (line 3)
In f3 (line 3)

f0var =

     0

> In f0 (line 3)
In f1 (line 4)
In f2 (line 3)
In f3 (line 3)

Your variables are:

f2var


Markus Mützel <mmuetzel>
Group administrator
Tue 12 Jan 2021 12:27:35 AM UTC, comment #3: 

File for comment #2 attached here.


(file #50705)

John W. Eaton <jwe>
Group administrator
Tue 12 Jan 2021 12:26:20 AM UTC, comment #2: 

With your test, were the functions in separate files?

Could someone try the following test in a current version of Matlab?  Unpack the attached file.  It will create a directory evalin-bug with the files f0.m, f1.m, f2.m, and f3.m.  In Matlab, call the function "f3" and report back with the output it produces.

Octave shows this:


octave:1> f3
f3var = 3
f2var = 2
f1var = 0
stopped in:

  --> f1 at line 3 [.../evalin-bug/f1.m]
      f2 at line 3 [.../evalin-bug/f2.m]
      f3 at line 3 [.../evalin-bug/f3.m]
f0var = 0
stopped in:

  --> f0 at line 3 [.../evalin-bug/f0.m]
      f1 at line 4 [.../evalin-bug/f1.m]
      f2 at line 3 [.../evalin-bug/f2.m]
      f3 at line 3 [.../evalin-bug/f3.m]
Variables visible from the current scope:

f1var


I'm especially curious about what the dbstack function reports here.

The issue is that when "evalin ('caller', 'f0')" is executed, the call to the function "f0" creates a new stack frame at the top of the call stack and the "caller" of that is the previous top of the stack (i.e., "f1") not the caller of "f1".  There is some warning about possible problems with using nested calls to evalin in the Matlab docs.  Note that if you use evalin in a script file or if you use evalin in local functions inside a script, you might see different results.

John W. Eaton <jwe>
Group administrator
Fri 08 Jan 2021 10:20:13 PM UTC, comment #1: 

Confirmed.  This is unexpected behavior and a regression from 5.2.0.  Matlab, and Octave in previous versions, print 'topvar' for either invocation.

Rik <rik5>
Group administrator
Fri 08 Jan 2021 08:18:10 PM UTC, original submission:  

Consider the following use case of evalin:


function f ()
  evalin ('caller', 'who')
end

function h ()
   hvar = 42;
   evalin ('caller', 'f')
end

>> topvar = 0
>> f ()
>> h ()


Result:

+verbarim+
topvar
hvar
-verbatim-

Expected result:


topvar
topvar


Torsten Lilge <ttl>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #50833:  stack-caller-info-diffs.txt added by jwe (15KiB - text/plain)
file #50709:  dbup-test.tar.gz added by jwe (359B - application/gzip)
file #50705:  evalin-bug.tar.gz added by jwe (304B - application/gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by ttl (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-02-04 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-02-04 jwe StatusConfirmed Ready For Test
    2021-02-04 jwe Attached File- Added stack-caller-info-diffs-v2.txt, #50835
    2021-02-03 jwe Attached File- Added stack-caller-info-diffs.txt, #50833
    2021-01-12 jwe Attached File- Added dbup-test.tar.gz, #50709
    2021-01-12 jwe Attached File- Added evalin-bug.tar.gz, #50705
    2021-01-08 rik5 Item GroupMatlab Compatibility Regression
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code