Octave 3.0.1 crashes deterministically in __qp__.cc

[Joshua Redstone]

Ah, sorry.Attached find a file named "example".
Here is a session reproducing the problem:

octave:2> load "./example"
octave:3> [X, OBJ, INFO, LAMBDA] = qp(x0, H, Q, A, B, LB, UB, A_LB, A_IN,
A_UB)

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x021ff000
0x02765e20 in qp (H=@0xbfffba40, q=@0xbfffba2c, Aeq=@0xbfffba18,
beq=@0xbfffba04, Ain=@0xbfffb9f0, bin=@0xbfffb9dc, maxit=200, x=@0xbfffb9c4,
lambda=@0xbfffb9b0, iter=@0xbfffb9d8) at __qp__.cc:362
362 Aact(n_eq+i,j) = Aact(n_eq+i+1,j);
(gdb) quit

Josh

On Tue, Jun 24, 2008 at 3:45 PM, John W. Eaton <jwe at bevo.che.wisc.edu>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/bug-octave/attachments/20080624/051addab/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example
Type: application/octet-stream
Size: 46115 bytes
Desc: not available
Url : https://www.cae.wisc.edu/pipermail/bug-octave/attachments/20080624/051addab/attachment-0001.obj