Octave 3.0.1 crashes deterministically in __qp__.cc

[John W. Eaton]

On 24-Jun-2008, Joshua Redstone wrote:

| Hi, On a certain workload, Octave is crashing for me deterministically on
| osx 10.5.2 using a prebuilt binary (from http://octave.sourceforge.net/).
| I downloaded the octave source, compiled it with:
|    make CFLAGS=-g CXXFLAGS=-g
| and reproduced the error in gdb.  It looks like at line 362, __qp__ is
| referencing a matrix out of bounds.
| Here is relevant output from the debug session:
| 
| Program received signal EXC_BAD_ACCESS, Could not access memory.
| Reason: KERN_INVALID_ADDRESS at address: 0x0278f000
| 0x042d0e20 in qp (H=@0xbfff6ef0, q=@0xbfff6edc, Aeq=@0xbfff6ec8,
| beq=@0xbfff6eb4, Ain=@0xbfff6ea0, bin=@0xbfff6e8c, maxit=200, x=@0xbfff6e74,
| lambda=@0xbfff6e60, iter=@0xbfff6e88) at __qp__.cc:362
| 362 Aact(n_eq+i,j) = Aact(n_eq+i+1,j);
| (gdb) p j
| $1 = 87
| Current language:  auto; currently c++
| (gdb) p n_eq
| $2 = 2
| (gdb) p i
| $3 = 61
| (gdb) p Aact
| $4 = {
|   <MArray2<double>> = {
|     <Array2<double>> = {
|       <Array<double>> = {
|         _vptr$Array = 0x13fda28,
|         rep = 0x26116a0,
|         dimensions = {
|           rep = 0x404d0d0
|         },
|         idx = 0x0,
|         idx_count = 0
|       }, <No data fields>}, <No data fields>}, <No data fields>}
| (gdb) p Aact.rows()
| $5 = 64
| (gdb) p Aact.columns()
| $6 = 88
| (gdb) p n_eq+i+1
| $7 = 64
| (gdb) p n
| $8 = 88
| (gdb) bt
| #0  0x042d0e20 in qp (H=@0xbfff6ef0, q=@0xbfff6edc, Aeq=@0xbfff6ec8,
| beq=@0xbfff6eb4, Ain=@0xbfff6ea0, bin=@0xbfff6e8c, maxit=200, x=@0xbfff6e74,
| lambda=@0xbfff6e60, iter=@0xbfff6e88) at __qp__.cc:362
| #1  0x042d1f0e in F__qp__ (args=@0x41a4708) at __qp__.cc:509
| #2  0x00fa2b07 in octave_builtin::do_multi_index_op (this=0x34675e0,
| nargout=4, args=@0x41a4708) at ov-builtin.cc:104
| #3  0x00fa2cba in octave_builtin::subsref (this=0x34675e0, type=@0x41947b4,
| idx=@0xbfff7200, nargout=4) at ov-builtin.cc:54
| #4  0x00f7d925 in octave_value::subsref (this=0xbfff720c, type=@0x41947b4,
| idx=@0xbfff7200, nargout=4) at ov.cc:783
| #5  0x0103f32f in tree_index_expression::rvalue (this=0x4194790, nargout=4)
| at pt-idx.cc:352
| #6  0x0102fc33 in tree_multi_assignment::rvalue (this=0x41948f0) at
| pt-assign.cc:362
| .......................
| 
| Is anyone else seeing this?

Can you provide an example problem that causes the problem for you?

jwe