Re: Lion make check woes

[Robinson, Melvin D]

On 1/15/12 12:00 AM, "marco atzeri" <address@hidden> wrote:

>On 1/14/2012 11:33 PM, Robinson, Melvin D wrote:
>> I'm still having difficulty with the make check and would appreciate
>> just a bit of guidance on how I can make some progress.
>>
>> With ATLAS installed I have the following problems with make check:
>>
>> src/DLD-FUNCTIONS/betainc.cc ........................... ***MESSAGE FROM
>> ROUTINE INITS IN LIBRARY SLATEC.
>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>> * Chebyshev series too short for specified accuracy
>> * ERROR NUMBER = 1
>> *
>> ***END OF MESSAGE
>>
>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>> 0 ERROR MESSAGE SUMMARY
>> LIBRARY SUBROUTINE MESSAGE START NERR LEVEL COUNT
>> SLATEC INITS Chebyshev series too 1 1 1
>>
>> ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>> * Chebyshev series too short for specified accuracy
>> * ERROR NUMBER = 1
>> *
>> ***END OF MESSAGE
>>
>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>> 0 ERROR MESSAGE SUMMARY
>> LIBRARY SUBROUTINE MESSAGE START NERR LEVEL COUNT
>> SLATEC INITS Chebyshev series too 1 1 2
>>
>> PASS 4/6 FAIL 2
>> src/DLD-FUNCTIONS/bsxfun.cc ............................ PASS 73/73
>> src/DLD-FUNCTIONS/cellfun.cc ........................... PASS 121/121
>> src/DLD-FUNCTIONS/chol.cc .............................. PASS 29/29
>> src/DLD-FUNCTIONS/conv2.cc ............................. PASS 4/4
>> src/DLD-FUNCTIONS/convhulln.cc ......................... PASS 2/3 FAIL 1
>> src/DLD-FUNCTIONS/dassl.cc ............................. PASS 4/4
>> src/DLD-FUNCTIONS/det.cc ............................... PASS 5/5
>> src/DLD-FUNCTIONS/dlmread.cc ........................... PASS 20/20
>> src/DLD-FUNCTIONS/dmperm.cc ............................ PASS 5/5
>> src/DLD-FUNCTIONS/dot.cc ...............................
>>
>> The convhulln test is one that I will have to work on, but I'm not
>> understanding why it would lock up in dot.cc. This is simply the source
>> code to comptes the dot product of vectors, right? I'm trying to narrow
>> this down
>>
>> octave:1> test dot.cc verbose
>>  >>>>> /Users/melrobin/octave/src/DLD-FUNCTIONS/dot.cc
>> ***** test
>> x = [2, 1; 2, 1];
>> y = [-0.5, 2; 0.5, -2];
>> assert(dot (x, y), [0 0]);
>> ***** test
>> x = [ 1+i, 3-i; 1-i, 3-i];
>> assert(dot (x, x), [4, 20]);
>>
>> At this point it is locks up. I verified this behavior by using
>> ./run-octave:
>>
>> octave:1> x = [ 1+i, 3-i; 1-i, 3-i];
>> octave:2> dot(x,x)
>>
>> and it locks up dotting x with itself. This smells like it is a bug with
>> ATLAS because I do not have the same issue when using -framework veclib
>> (the default BLAS/LAPACK for Mac OS X). My problem using -framework
>> veclib is that it segfaults on eigs.cc, but one problem at a time.
>>
>> I would like to recreate this problem for this test case by calling
>> ATLAS directly. Can you tell me what call dot(x,x) makes for complex
>> values? I'm going to try it with zdot, but wanted to make sure that I
>> know what I'm talking about.
>>
>> Thanks for your help.
>>
>
>which octave and atlas/lapack versions ?
>
>

I'm using ATLAS 3.9.63, granted it is a developer version, but it passes
all the checks.   A few versions ago of ATLAS John helped to narrow down
which call was causing a segfault and I wanted to do the same again by
preparing a small test case that calls ATLAS directly.  I'm using the
latest Octave developer sources.