64bit foundation bug in Octave2.9.3

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

64bit foundation bug in Octave2.9.3

Clinton Chee
Version 2.9.3
Platform: SGI Altix Itanium2 (linux)
Compilers: Intel F/C/CC


Dear All,

I was following up on Daniel's test of simple indexing to stress test
the octave64 capability.

ccc(2^4)=0;

this should create a vector of 16 entries filled with zeros
and it works!

ccc(2^32)=0;

this should create a vector of 4294967296 entries filled with zeros
BUT it doesn't

After some investigation, I found:
ccc(2^31) --> octave thinks it is ---> ccc(2147483648) CORRECT
ccc(2^31+50) --> octave thinks it is ---> ccc( -2147483598) WRONG
ccc(2^31+100) --> octave thinks it is ---> ccc( -2147483548) WRONG
ccc(2^32) --> octave thinks it is ---> ccc(0) WRONG

In short, there's an error in the indexing which still seems to be "int"
instead of the "octave_idx_type" index which I supposed to have change.

I tried tracing the bug but can't really nail it down. I can't find
which class or function which I've missed changing the index. From the
backtrace of a process that is actually giving the right result (eg,
ccc(2^30) = 0; ), the following backtrace from gdb is obtained.



octave:1> ccc(2^30)=0;

Program received signal SIGINT, Interrupt.
[Switching to Thread 2305843009213902096 (LWP 1607)]
0x4000000003250b40 in Array<double>::resize_and_fill () at Array.cc:745
745             xelem (i) = val;
Current language:  auto; currently c++
(gdb) bt
#0  0x4000000003250b40 in Array<double>::resize_and_fill () at Array.cc:745
#1  0x400000000328b500 in assign1 (rhs=@0x2000000003401d00,
    rfv=@0xe000000000000000) at Array.cc:2488
#2  0x40000000032899e0 in assign2<double, double> () at Array.cc:2737
#3  0x400000000328bd00 in assign (lhs=@0x0, rhs=@0x60000fffffff9670,
rfv=@0x0)
    at Array.cc:2434
#4  0x400000000084d320 in octave_base_matrix<NDArray>::assign ()
    at ov-base-mat.cc:207
#5  0x40000000017ca910 in oct_assignop_assign (idx=@0x0)
    at ./OPERATORS/op-m-s.cc:106
#6  0x4000000000a07270 in numeric_assign (this=0x10,
type=@0x60000000001317f8,
    idx=@0x2000000003401ae0, rhs=@0x6000000000c8c908) at ov.cc:1510
#7  0x4000000000851a40 in octave_base_matrix<NDArray>::subsasgn ()
    at ov-base-mat.cc:84
#8  0x40000000009ec9e0 in subsasgn (this=0x6000000000a70900, type=@0x60,
    idx=@0x6000000000a70900, rhs=@0x6000000000a70900) at ov.cc:909
#9  0x40000000007e1430 in subsasgn (this=0x60000fffffff9ec0,
    type=@0x60000000001347b0, idx=@0x6000000000020b70,
rhs=@0x60000000001288c0)
    at ov-base.cc:173
#10 0x40000000009ec9e0 in subsasgn (this=0x60000fffffff9ec0,
    type=@0x60000000001347b0, idx=@0x6000000000020b70,
rhs=@0x60000000001288c0)
    at ov.cc:909
#11 0x40000000009ef5d0 in octave_value::assign () at ov.cc:956
#12 0x40000000015682c0 in assign (rhs=@0x6000000000020b70) at
oct-lvalue.cc:37
#13 0x40000000010bcb40 in tree_simple_assignment::rvalue () at
pt-assign.cc:107
#14 0x40000000010bda90 in rvalue (nargout=2) at pt-assign.cc:70
#15 0x40000000011c8300 in tree_statement::eval () at pt-stmt.cc:136
#16 0x40000000011cabd0 in tree_statement_list::eval () at pt-stmt.cc:171
#17 0x400000000076c1a0 in main_loop () at toplev.cc:168
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) quit
The program is running.  Exit anyway? (y or n) y



*** Please note that the line numbers above may be different from the
real 2.9.3 version, since I am using my own development version.


Thanks
---------------------------------------------------------------------------
Clinton Chee
Computational Scientist
High Performance Computing Unit
Room 2075, Red Centre
University of New South Wales
Australia 2035
chee at parallel stop hpc stop unsw stop edu stop au
Tel: 61 2 9385 6915
----------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

64bit foundation bug in Octave2.9.3

John W. Eaton-6
On 15-Jun-2005, Clinton Chee wrote:

| Version 2.9.3
| Platform: SGI Altix Itanium2 (linux)
| Compilers: Intel F/C/CC
|
|
| Dear All,
|
| I was following up on Daniel's test of simple indexing to stress test
| the octave64 capability.
|
| ccc(2^4)=0;
|
| this should create a vector of 16 entries filled with zeros
| and it works!
|
| ccc(2^32)=0;
|
| this should create a vector of 4294967296 entries filled with zeros
| BUT it doesn't
|
| After some investigation, I found:
| ccc(2^31) --> octave thinks it is ---> ccc(2147483648) CORRECT
| ccc(2^31+50) --> octave thinks it is ---> ccc( -2147483598) WRONG
| ccc(2^31+100) --> octave thinks it is ---> ccc( -2147483548) WRONG
| ccc(2^32) --> octave thinks it is ---> ccc(0) WRONG
|
| In short, there's an error in the indexing which still seems to be "int"
| instead of the "octave_idx_type" index which I supposed to have change.
|
| I tried tracing the bug but can't really nail it down. I can't find
| which class or function which I've missed changing the index. From the
| backtrace of a process that is actually giving the right result (eg,
| ccc(2^30) = 0; ), the following backtrace from gdb is obtained.

The following patch fixes a potential problem like this, but I'm not
sure that this code is involved in the particular problem you cite.

jwe


liboctave/ChangeLog:

2005-06-15  John W. Eaton  <[hidden email]>

        * Array.h (Array::resize): Change int args to octave_idx_type.


Index: liboctave/Array.h
===================================================================
RCS file: /cvs/octave/liboctave/Array.h,v
retrieving revision 1.93
diff -u -r1.93 Array.h
--- liboctave/Array.h 26 Apr 2005 19:24:27 -0000 1.93
+++ liboctave/Array.h 15 Jun 2005 13:45:39 -0000
@@ -451,9 +451,9 @@
 
 public:
 
-  void resize (int n) { resize_no_fill (n); }
+  void resize (octave_idx_type n) { resize_no_fill (n); }
 
-  void resize (int n, const T& val) { resize_and_fill (n, val); }
+  void resize (octave_idx_type n, const T& val) { resize_and_fill (n, val); }
 
   void resize (const dim_vector& dv) { resize_no_fill (dv); }
 

Reply | Threaded
Open this post in threaded view
|

64bit foundation bug in Octave2.9.3

John W. Eaton-6
In reply to this post by Clinton Chee
On 15-Jun-2005, Clinton Chee wrote:

| Version 2.9.3
| Platform: SGI Altix Itanium2 (linux)
| Compilers: Intel F/C/CC
|
|
| Dear All,
|
| I was following up on Daniel's test of simple indexing to stress test
| the octave64 capability.
|
| ccc(2^4)=0;
|
| this should create a vector of 16 entries filled with zeros
| and it works!
|
| ccc(2^32)=0;
|
| this should create a vector of 4294967296 entries filled with zeros
| BUT it doesn't
|
| After some investigation, I found:
| ccc(2^31) --> octave thinks it is ---> ccc(2147483648) CORRECT
| ccc(2^31+50) --> octave thinks it is ---> ccc( -2147483598) WRONG
| ccc(2^31+100) --> octave thinks it is ---> ccc( -2147483548) WRONG
| ccc(2^32) --> octave thinks it is ---> ccc(0) WRONG
|
| In short, there's an error in the indexing which still seems to be "int"
| instead of the "octave_idx_type" index which I supposed to have change.
|
| I tried tracing the bug but can't really nail it down. I can't find
| which class or function which I've missed changing the index. From the
| backtrace of a process that is actually giving the right result (eg,
| ccc(2^30) = 0; ), the following backtrace from gdb is obtained.

I did a liitle more checking on a 64-bit system with the latest CVS
sources and when I try

  x(2^32) = 0;

and break in

  Array<double>::resize_and_fill (octave_idx_type n, const double& val)

the value of N is 4294967296.  On the system I'm using, this
subsequently fails with an out of memory message, but I don't see that
anything is incorrect in the indexing.

jwe