|
Octave 3.0.1 crashes deterministically in __qp__.cc
Hi, 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? Josh _______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Octave 3.0.1 crashes deterministically in __qp__.cc
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
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
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@...> 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?
jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
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
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
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. 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 On 24-Jun-2008, Joshua Redstone wrote:
| Hi, On a certain workload, Octave is crashing for me deterministically on . | 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>> = { | _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
_______________________________________________ Bug-octave mailing list
Marius -- Marius Schamschula Webmaster
The Huntsville Macintosh Users Group www.hmug.org
webmaster at hmug dot org marius at schamschula dot com
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
On Tue, Jun 24, 2008 at 6:51 PM, Marius Schamschula < marius173@...> wrote:
> 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.
I suspect that those were built with AltiVec and Fink's with ATLAS proper...
Dmitri.
--
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
On Jun 24, 2008, at 7:51 PM, Marius Schamschula wrote:
>
> 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.
>
Ok, I tried the 'example' on my G4 (ppc) Mac (also running 10.5.3). A
core dump & seg-fault resulted. I also tried the example again on the
Intel Mac, still no problem for me there.
Ben
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
On Jun 24, 2008, at 8:01 PM, Dmitri A. Sergatskov wrote:
> On Tue, Jun 24, 2008 at 6:51 PM, Marius Schamschula < marius173@...
> > wrote:
>> 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.
>
> I suspect that those were built with AltiVec and Fink's with ATLAS
> proper...
>
> Dmitri.
> --
I checked my Intel build, it does not use ATLAS and was built using
following snippet from the info file
--------- snip ----------
ConfigureParams:
c = FLIBS=%p/lib/gcc4.3/lib/libgfortran.dylib F77=%p/bin/gfortran --
infodir='${prefix}/share/info' --mandir='${prefix}/share/man' --
libexecdir='${prefix}/lib' -enable-shared -enable-dl --disable-static
--without-mpi --with-hdf5 --with-fftw
CompileScript: <<
#!/bin/sh -ev
export CFLAGS='-O3'
export CXXFLAGS='-O3'
export FFLAGS='-O3'
if [ "%type_pkg[-atlas]" == "" ]
then a='--with-lapack=-Wl,-framework,Accelerate,-dylib_file,/System/
Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/
vecLib.framework/Versions/A/libLAPACK.dylib:/System/Library/Frameworks/
Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/
libLAPACK.dylib --with-blas=-Wl,-framework,Accelerate,-dylib_file,/
System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/
vecLib.framework/Versions/A/libBLAS.dylib:/System/Library/Frameworks/
Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/
libBLAS.dylib'
else a='--with-lapack=%p/lib/liblapack.dylib --with-blas=%p/lib/
libf77blas.dylib'
fi
./configure %c $a
make
--------- snip ----------
The %c refers to "ConfigParams" and ${prefix} is "/sw"
I'll try building the Atlas version on my ppc tonight and report the
results tomorrow.
Ben
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
On Tue, Jun 24, 2008 at 7:25 PM, Ben Abbott < bpabbott@...> wrote:
>
> I checked my Intel build, it does not use ATLAS and was built using
> following snippet from the info file
>
> --------- snip ----------
> ConfigureParams:
> c = FLIBS=%p/lib/gcc4.3/lib/libgfortran.dylib F77=%p/bin/gfortran
...
What does "otool -L /mypath/to/octave " return?
Dmitri.
--
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
On Jun 24, 2008, at 7:01 PM, Dmitri A. Sergatskov wrote: On Tue, Jun 24, 2008 at 6:51 PM, Marius Schamschula < marius173@...> wrote: 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.
I suspect that those were built with AltiVec and Fink's with ATLAS proper...
Dmitri. --
ATLAS proper?
Isn't the Accelerate Framework built from ATLAS sources?
The difference is that ATLAS tends to be more up to date in terms of bug fixes, than is the Framework.
I gave up on hand building ATLAS many years ago, i.e. build for G4 single & dual, G5, single, dual & quad, Intel 32bit, single & dual, Intel 64bit dual, quad & octo... ...never mind the various sub-variants of these processors.
Who has the time, especially if Apple already has done the work in a more processor neutral way. Building against ATLAS also prevents building Octave.app (and other binary distributions, like Guarv's and mine), since you would need a separate build for each processor configuration. I currently build four versions PPC/Intel * 10.4/10.5.
BTW: note that octave with ATLAS is a Fink variant, octave can also be build w/o ATLAS. using the Framework. Marius -- Marius Schamschula Webmaster
The Huntsville Macintosh Users Group www.hmug.org
webmaster at hmug dot org marius at schamschula dot com
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
On Tue, Jun 24, 2008 at 8:33 PM, Marius Schamschula < marius173@...> wrote:
>
> I suspect that those were built with AltiVec and Fink's with ATLAS proper...
> Dmitri.
> --
>
> ATLAS proper?
> Isn't the Accelerate Framework built from ATLAS sources?
Apple obviously used 3.6.0 snapshot, but kind of shy in admitting it...
> The difference is that ATLAS tends to be more up to date in terms of bug
> fixes, than is the Framework.
Yes.
> BTW: note that octave with ATLAS is a Fink variant, octave can also be build
> w/o ATLAS. using the Framework.
>
That is pretty much my point -- there are many different ways to
compile octave on MacOS, so could you all please tell us more
than just "octave on my Mac works"? BLAS version and gcc
version would be helpful (some gcc 4.2.x made bad binaries on
linux, as far as I remember); otool -L could be helpful as well.
> Marius
Regards,
Dmitri.
--
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
On Jun 24, 2008, at 8:25 PM, Ben Abbott wrote:
>
> On Jun 24, 2008, at 8:01 PM, Dmitri A. Sergatskov wrote:
>
>> On Tue, Jun 24, 2008 at 6:51 PM, Marius Schamschula < marius173@...
>>> wrote:
>>> 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.
>>
>> I suspect that those were built with AltiVec and Fink's with ATLAS
>> proper...
>>
>> Dmitri.
>> --
>
> I checked my Intel build, it does not use ATLAS and was built using
> following snippet from the info file
>
> --------- snip ----------
> ConfigureParams:
> c = FLIBS=%p/lib/gcc4.3/lib/libgfortran.dylib F77=%p/bin/gfortran --
> infodir='${prefix}/share/info' --mandir='${prefix}/share/man' --
> libexecdir='${prefix}/lib' -enable-shared -enable-dl --disable-static
> --without-mpi --with-hdf5 --with-fftw
> CompileScript: <<
> #!/bin/sh -ev
> export CFLAGS='-O3'
> export CXXFLAGS='-O3'
> export FFLAGS='-O3'
> if [ "%type_pkg[-atlas]" == "" ]
> then a='--with-lapack=-Wl,-framework,Accelerate,-dylib_file,/System/
> Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/
> vecLib.framework/Versions/A/libLAPACK.dylib:/System/Library/
> Frameworks/
> Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/
> A/
> libLAPACK.dylib --with-blas=-Wl,-framework,Accelerate,-dylib_file,/
> System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/
> vecLib.framework/Versions/A/libBLAS.dylib:/System/Library/Frameworks/
> Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/
> A/
> libBLAS.dylib'
> else a='--with-lapack=%p/lib/liblapack.dylib --with-blas=%p/lib/
> libf77blas.dylib'
> fi
> ./configure %c $a
> make
> --------- snip ----------
>
> The %c refers to "ConfigParams" and ${prefix} is "/sw"
>
> I'll try building the Atlas version on my ppc tonight and report the
> results tomorrow.
>
> Ben
Octave 3.0.1 built with ATLAS on my G4 (ppc) running 10.5.3 also core-
dumped.
Ben
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
|
|
Re: Octave 3.0.1 crashes deterministically in __qp__.cc
|
example (61K)