Seg. fault with roots(b)
Jason Riedy
jason at acm.org
Tue May 5 16:54:54 CDT 2009
And Robert Jenssen writes with John W. Eaton annotating:
> | (gdb) p A
> | $5 = (PTR TO -> ( real*8 (0:-1))) 0x2b6eb000
> | (gdb) up
> | #1 0x293154c1 in dgeev (jobvl=@0x293f99cf, jobvr=@0x293f99cf, n=@0xbfbfd2a4,
> | a=0x2b6eb000, lda=@0xbfbfd2a4, wr=0x29d022f0, wi=0x29d023a0, vl=0x0,
> | ldvl=@0xbfbfd298, vr=0x29d1b292, ldvr=@0xbfbfd2a4, work=0x2b900000,
> | lwork=@0xbfbfd29c, info=@0xbfbfd2a0, _jobvl=1, _jobvr=1) at dgeev.f:241
> | 241 ANRM = DLANGE( 'M', N, N, A, LDA, DUM )
>
> What is the value of N here?
The sudden onset of employment has slowed my response, but I'd be
grateful if someone who can reproduce this would try to isolate the
bug. If it's on the LAPACK side, I'll either pass it along or work
on it.
It *could* be a mismatch in either the Fortran calling convention
or the expected size of int v. INTEGER. Those are the most common
culprits I've seen for suddenly huge dimensions... The debugger
info has the dimensions as 4-byte integers, so that *looks* right.
But I can't reproduce the problem...
Jason
More information about the Bug-octave
mailing list