bugGNU Octave - Bugs: bug #41756, assert wrongly returning no error

 
 

bug #41756: assert wrongly returning no error

Submitter:  John Hunt <huntj>
Submitted:  Sun 02 Mar 2014 08:15:39 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.8.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 05 Mar 2014 05:38:59 AM UTC, comment #4: 

I checked in the following changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/9472e3c8f43e

This change seems to fix the problem for me.  The diff is only large because it indents most of the function.  It really just adds an unwind_protect block to handle resetting the value of call_depth.

John W. Eaton <jwe>
Group administrator
Wed 05 Mar 2014 05:35:20 AM UTC, comment #3: 

seems like a job for unwind_protect; please let me know if you think that wouldn't work for some reason. thx.

Felipe G. Nievinski <fgnievinski>
Wed 05 Mar 2014 04:22:22 AM UTC, comment #2: 

This is a regression from 3.6.4.  The problem appears to be in the m-file assert.m.  There is a persistent variable call_depth which is used to keep track of recursion in the function.  When Ctrl+C interrupts assert the variable is left in an incorrect state.  Using 'clear -f assert' will re-initialize the call_depth variable and bring back the correct behavior.

Long term, either the code needs to change not to use this style or Ctrl+C needs to be trapped by assert so that it can re-initialize the call_depth variable.

The following code is somewhat simpler and reproduces the problem.


a = 1:10e5;
b = a;
assert (a, b)
^C
assert (0, 1)
# No error
clear -f assert
assert (0, 1)
error: ASSERT errors for:  assert (0,1)

  Location  |  Observed  |  Expected  |  Reason
     ()           0            1         Abs err 1 exceeds tol 0


Rik <rik5>
Group administrator
Sun 02 Mar 2014 08:24:31 PM UTC, comment #1: 

This is indeed related to a Ctrl-C during a long assert.
Here is how to reproduce.


octave:4> a=1:10000;
octave:5> b = a;
octave:6> b(end) = 2;
octave:7> tic; assert(a, b); toc
error: ASSERT errors for:  assert (a,b)

  Location  |  Observed  |  Expected  |  Reason
  (10000)       10000          2         Abs err 9998 exceeds tol 0
octave:7> tic; assert(a, b+1); toc
^C
octave:7> tic; assert(a, b); toc
Elapsed time is 0.030268 seconds.
octave:8> tic; assert(a, b+1); toc
Elapsed time is 12.4797 seconds.


John Hunt <huntj>
Sun 02 Mar 2014 08:15:39 PM UTC, original submission:  

A weird behavior, probably due to a Ctrl-C during a long test,
and perhaps related to persistent variables in assert.
Can not be reproduced in a fresh octave session.


octave:232> assert(1, 2)
octave:233> OCTAVE_VERSION
ans = 3.8.0
octave:234> test assert
  ***** error <O(3x0)s+E(0x2)> assert (zeros (3,0), zeros (0,2))
!!!!! error failed.
Expected <O(3x0)s+E(0x2)> but got no error
octave:236> assert(false) # this one is OK
error: assert (false) failed


It seems that the error messages are evaluated, although not printed, since when there are differences the elapsed time is longer.

octave:245> tic; assert(1:10000, (1:10000)+1); toc
Elapsed time is 13.1188 seconds.
octave:246> tic; assert(1:10000, (1:10000)); toc
Elapsed time is 0.0127668 seconds.


John Hunt <huntj>

 

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

Attach Files:
   
   
Comment:
   

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 fgnievinski (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by huntj (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
    2014-03-05 jwe StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2014-03-05 rik5 Item GroupIncorrect Result Regression
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code