Re: Octave 3.0.1 crashes deterministically in __qp__.cc

>
> On Jun 24, 2008, at 6:22 PM, Ben Abbott wrote:
>
>>
>> On Jun 24, 2008, at 7:02 PM, Joshua Redstone wrote:
>>>
>>> On Tue, Jun 24, 2008 at 3:45 PM, John W. Eaton
>>> <jwe@...> 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
>>>
>>> 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
>>
>> As I am presently running 3.0.1 on Mac OSX 10.5.3 (Intel), I thought
>> I'd try the example.
>>
>> I encountered no errors.
>>
>> My binary was built using Fink's package manager.
>>
>> Ben
>>
>
> John, Ben,
>
> I just tried this on my (www.hmug.org) builds of octave 3.0.1; once  
> on a G5 (PPC) running Mac OS X 10.4.11, and also on a MacBook Pro  
> (Intel) running 10.5.3. I get a core dump in both cases.
>