bugGNU Octave - Bugs: bug #38236, invoking script in demo block to...


bug #38236: invoking script in demo block to define variables causes errors

Submitted by:  Carlo de Falco <cdf>
Submitted on:  Sat Feb 2 16:09:00 2013  
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: NoneAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

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


(Jump to the original submission Jump to the original submission)

Fri Jan 15 23:30:04 2016, comment #18:

Since jwe said regressions are high priority bugs, I'm looking into this.

The problem seems to be that df_vr creates a vr symbol in the context of _demo_, but that symbol isn't cleared when _demo_ is. Issuing "who" just after "v=7" in df_vr doesn't return anything the second time around. The assignment is to the original symbol (it consistently has the same "this" address) but that symbol is not found in the context of the new _demo_.

The problem goes away if "clear -f df_vr" is issued when "clear _demo_" is issued.

Debugging this is made hard by my lack of understanding of how things are supposed to work. I had assumed that variables are created on the fly during a function, but it seems that they are all created when the file is parsed and instantiated with <unknown value>. I assume that this is to avoid a string-based look-up for every variable reference, right? How is reuse of the script in different contexts supposed to work?

Each symbol seems to have its own value_stack indexed by context. Is context numbered sequentially in the number of stack frames? I assume that there isn't a value of each symbol for each stack frame, just the ones in which the variable occurs, right? If so, are there "gaps" in the value_stack?

Thanks for your help!

Lachlan Andrew <lachlan>
Project Member
Thu Mar 21 09:34:59 2013, comment #17:

After pulling and updating, the last effect described in the previous comment disappeared, it was probably due to bug #38549
which was fixed by this changeset:

changeset: 16337:6bfd8dbd7d3c
user: John W. Eaton <jwe@octave.org>
date: Tue Mar 19 18:03:23 2013 -0400
summary: don't swallow statements that follow comment lines (bug #38549)


Carlo de Falco <cdf>
Project Member
Thu Mar 21 07:27:44 2013, comment #16:


The tests I had attached below (which are in the source tree in
test/bug-38236) are already implemented without calling demo.m

u_vr.m can be further simplified as follows:

# u_vr.m

## define and exectute "__demo__" once
eval ("function _demo_ (); df_vr; v = vr * 2; endfunction");

## clear definition of "__demo__"
clear _demo_

## define and exectute "__demo__" once more
eval ("function _demo_ (); df_vr; v = vr * 2; endfunction");


running some more experiments I noted even more oddities:

1) If the code avove is in a script file named u_vr, invoking
the script once gives an error, but all subsequent invocations
of u_vr do not err out:

2) If I remove the "eval" command in u_vr and just redefine the function '__demo__' there is never any error:

3) Now this is the most amazing and unexpected effect I see.
If, rather than running the script u_vr I just copy the commands to the prompt, I get no error

_BUT_, if I also copy the commented lines to the prompt, I get a DIFFERENT error:

I'll push the simplified version of u_vr.m to mercurial.

Carlo de Falco <cdf>
Project Member
Wed Mar 20 20:25:21 2013, comment #15:

I've made an abbreviated set of files which demonstrates the problem without having to use demo.m. I'm attaching the files, block1.m, block2.m, block3.m. to this report.

To see the problem, run block1 twice.

Sample code:

What you can see from running is that the assignment statement is executed, vr = 7, and echoed to the screen. But, the symbol table is not updated with actual values. I had a keyboard() statement in block3.m and could see that nothing was defined during the second run of block1. Manual assignment of variables at the debug prompt did work. So the symbol table was not entirely messed up.

Another oddity is that if the lowest level function is removed before each run the code will always work.


(file #27640, file #27641, file #27642)

Rik <rik5>
Project Administrator
Wed Mar 20 10:04:48 2013, comment #14:

I finished bisecting and arrived at the same conclusion as Rik concerning the first bad revision.

Julien Bect <jbect>
Wed Mar 20 08:43:13 2013, comment #13:

Before the patch for bug 34497, clear _debug_ did not actually clear the _debug_ function (as it was defined on the command line).

So, it looks like there is some problem caused by actually clearing _debug_.

Max Brister <fisheater>
Project Member
Wed Mar 20 01:33:48 2013, comment #12:

The changeset that causes the problem for me, from hg bisect, is

As I thought, it is something with clearing functions. I'll e-mail Max and see if he recalls anything about this changeset.

Rik <rik5>
Project Administrator
Tue Mar 19 17:47:47 2013, comment #11:

In the meantime I keep on bisecting ;-)

bad : 3d8ace26c5b4 (Thu, 26 Jul 2012 08:13:22)

good : 0ef151f9fdc9 (Fri, 20 Jul 2012 16:13:35)

The regression happened last July.

Julien Bect <jbect>
Tue Mar 19 17:37:37 2013, comment #10:

I think this problem is related to problems clearing functions.

Inside test.m we use eval to create a function that has the %!test code inside it. We then execute that function and clear it when we are done. I made a small cset where I made the name of the function unique by just adding an incrementing counter to the function name and this bug disappeared. I'll see if I can find the cset and attach it. It really wasn't meant as a fix though, just a way to diagnose the problem.

Rik <rik5>
Project Administrator
Tue Mar 19 15:25:48 2013, comment #9:

Just to keep you informed: I'm still bisecting, at the moment I've narrowed it down to 80 changesets ;-)

Julien Bect <jbect>
Mon Mar 18 17:51:04 2013, comment #8:

On my system I have installed the development version
and version 3.6.2 and I get:


I don't have 3.6.4 installed.
So maybe we can conclude the offending
changeset is between the 3.6.2 release tag
and changeset d048ef58bb72?

As I said in a post on the list I am unable
to do an "hg bisect" as many versions fail to build
on my system so I cannot run the test at all intermediate

Carlo de Falco <cdf>
Project Member
Mon Mar 18 15:22:56 2013, comment #7:

If you're digging blindly, you might like Mercurial's bisect feature:


Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Mon Mar 18 15:13:56 2013, comment #6:

The problem was already there on default cs d048ef58bb72


I will dig further in the past.

Julien Bect <jbect>
Tue Feb 5 14:45:14 2013, comment #5:

you're right sorry, I just pushed a new changeset.



Carlo de Falco <cdf>
Project Member
Tue Feb 5 13:08:02 2013, comment #4:

Apparently you forgot to include the new files (test/bug-38236/*) in your changeset.

Julien Bect <jbect>
Tue Feb 5 09:38:27 2013, comment #3:

looking at how actually simple the function "demo ()" is,
I think the bug is probably rather in eval or clear.
While I try to look more deeply into this issue, I pushed a changeset:


with a test for this bug that does not use demo.
Probably I should change the title for this bug report but
I can not come up with a better one at the moment.

Carlo de Falco <cdf>
Project Member
Tue Feb 5 06:49:34 2013, comment #2:

forget my previous post, it was just my mistake, even with JIT disabled the error is still there, sorry for the noise.

Carlo de Falco <cdf>
Project Member
Tue Feb 5 05:44:56 2013, comment #1:

with JIT disabled at configure time the problem seems
to disappear.


Carlo de Falco <cdf>
Project Member
Sat Feb 2 16:09:00 2013, original submission:

let the file 'df_vr.m' contain the following

and the file 'u_vr' be as follows

running 'demo u_vr' once gives a correct result:

but running the same command a second time causes an error

I marked this as a regression because it seems to work correctly
in the stable release (at least on 3.6.3, I do not have a build of 3.6.4 to try on)

I attach copies of the two simple scripts above for testing convenience.


Carlo de Falco <cdf>
Project Member


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

Attach File(s):

Attached Files
file #27640:  block1.m added by rik5 (217B - text/x-octave)
file #27641:  block3.m added by rik5 (148B - text/x-octave)
file #27642:  block2.m added by rik5 (62B - text/x-octave)
file #27371:  u_vr.m added by cdf (102B - application/octet-stream)
file #27370:  df_vr.m added by cdf (8B - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by lachlan (Posted a comment)
  • -unavailable- added by cbm
  • -unavailable- added by rik5
  • -unavailable- added by fisheater (Posted a comment)
  • -unavailable- added by rik5
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by jbect (Posted a comment)
  • -unavailable- added by cdf (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 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Jul 7 17:02:27 2014cbmCarbon-Copy-=>Added -unavailable-
    Wed Mar 20 20:25:21 2013rik5Attached File-=>Added block1.m, #27640
      Attached File-=>Added block3.m, #27641
      Attached File-=>Added block2.m, #27642
      Carbon-Copy-=>Added jwe
    Wed Mar 20 01:33:48 2013rik5Summaryinvoking script in demo block to define varibles causes errors=>invoking script in demo block to define variables causes errors
      Carbon-Copy-=>Added -unavailable-
    Sat Feb 2 16:09:00 2013cdfAttached File-=>Added df_vr.m, #27370
      Attached File-=>Added u_vr.m, #27371

    Back to the top

    Powered by Savane 3.1-cleanup1