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