failed build with current mercurial sources

[Ben Abbott]

On Mar 11, 2008, at 1:25 PM, Ben Abbott wrote:

>
> 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've gone through the effort of  recompiling all my dependencies using  
gcc/gfortran 4.2

The qr failure is not in the past tense, but I still have problems  
with the pcg test. The problem there respects mldivide.

octave:1> mldivide (2*eye(100) + circshift (eye (100), 1), ones (100,  
1));
panic: Bus error -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete

Unfortunately, I'm not able to get consistent results from the  
debugger. For example;

> ./run-octave -g
> (gdb) b data.cc:3476
> (gdb) run
> >> mldivide (2*eye(100) + circshift (eye (100), 1), ones (100, 1));
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000030
> [Switching to process 70593 thread 0x1003]
> 0x02e64f2f in ATL_dupMBmm0_6_0_b1 ()
> (gdb)
>
> (gdb) list
> 26	
> 27	#include "f77-fcn.h"
> 28	#include "lo-ieee.h"
> 29	
> 30	#include "octave.h"
> 31	
> 32	int
> 33	main (int argc, char **argv)
> 34	{
> 35	  return octave_main (argc, argv, 0);
> (gdb) bt
> #0  0x02e64f2f in ATL_dupMBmm0_6_0_b1 ()
> #1  0x0069f820 in ?? ()
> Cannot access memory at address 0x560

I tried stepping one line at a time. That resulted in

> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000008
> 0x01010f9f in mx_leftdiv_conform<Matrix, Matrix> (a=@0x64, b=@0x0)  
> at xdiv.cc:61
> 61	  octave_idx_type b_nr = b.rows ();

Unfortunately, I was unable to reproduce that by placing a break in  
xdiv.cc. Instead, the crash occurred ...

> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000030
> [Switching to process 71296 thread 0x1003]
> 0x02e64f2f in ATL_dupMBmm0_6_0_b1 () at iostream:76
> 76	  static ios_base::Init __ioinit;

Since the crash is not reproducible, I'm lost as to how to proceed  
with gdb ... I'm not exactly an expert in debugging such things, if  
there is another tool that might help, please school me ;-)

Presently, I'm thinking my problem (Mac OSX 10.5.2) is related to  
lapack/blas. I'm using ATLAS 3.8.0-6 from Fink. Previously, I'd used  
Apple's vecLib/Framework, but it was built using gcc 4.0.1 ... which  
has some compatibility issues with later versions of gfortran (i.e.  
the one I'm using) :-(

As I'm not up to speed on what recent changes to Octave might have  
impacted mldivide, I'm hoping for some assistance.

Might my problem be related to problems with xGELSD? ... or something  
else all together?

Ben