failed build with current mercurial sources

[Ben Abbott]

On Mar 11, 2008, at 11:01 AM, John W. Eaton wrote:

> On 11-Mar-2008, Ben Abbott wrote:
>
> | Program received signal EXC_BAD_ACCESS, Could not access memory.
> | Reason: 13 at address: 0x00000000
> | 0x8fe18b42 in __dyld_misaligned_stack_error ()
> | (gdb) bt 6
> | #0  0x8fe18b42 in __dyld_misaligned_stack_error ()
> | #1  0x94a0b2b5 in atl_f77wrap_zdotc__ ()
> | #2  0x0017e489 in zqrqhv_ (m=@0xbfffa70c, n=@0xbfffa708,
> | k=@0xbfffa704, q=0x31f68f0, ldq=@0xbfffa70c, r=0x31f6800,
> | ldr=@0xbfffa70c, u=0x31f5710, rr=@0xbfffa648) at zqrqhv.f:69
>
> The ZDOTC function is a Fortran function returning double complex.
> There was a recent gfortran change in calling conventions for
> functions (not subroutines) that return complex variables.  I suspect
> you are mixing the two methods here, compiling zqrqhv with a compiler
> that implements one of the methods, and using a version of ATLAS that
> was compiled to use the other.
>
> jwe

ok, I built ATLAS and modified the octave build to use my Altas rather  
than that used by Apple.

Nice deduction, John. The test of qr now passes!

However, now the pcg test produces a "Bus error"

octave:1> test pcg
panic: Bus error -- stopping myself...

I narrowed down the problem using the short script below.

more off

for N = 10:100;
   A = zeros (N, N);
   for i=1 : N - 1 # form 1-D Laplacian matrix
     A (i:i+1, i:i+1) = [2 -1; -1 2];
   endfor
   b = rand (N, 1);
   disp(sprintf('N = %d; X = A \\ B;',N))
   X = A \ b;
endfor

Which produces ...

[...]
N = 95; X = A \ B;
N = 96; X = A \ B;
N = 97; X = A \ B;
panic: Bus error -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Bus error

So the problem doesn't seem to be with pcg, but with "\" :-(

I'll spend some more time digging deeper using gdb, but thought I'd  
post in the event someone has a thought on what I might try to resolve  
this.

... I'm beginning to feel like Alice running down the rabbit hole :-(

Ben