failed build with current mercurial sources

Ben Abbott bpabbott at mac.com
Tue Mar 11 09:37:34 CDT 2008


On Mar 7, 2008, at 12:34 PM, Ben Abbott wrote:

> My default build process scraps the result in the event an error  
> occurs. Give me a few more hours and and get back to you.
>
> Ben
>
> On Friday, March 07, 2008, at 11:27AM, "Jaroslav Hajek" <highegg at gmail.com 
> > wrote:
>> Can you please run "test qr verbose" to reveal which test gives the  
>> segfault?
>> Also,please tell me your system configuration (in particular what C++
>> and Fortran compilers you use).
>>
>> On Fri, Mar 7, 2008 at 1:58 PM, Ben Abbott <bpabbott at mac.com> wrote:
>>> I tried to build the most recent mercurial sources a moment ago.
>>>
>>> "hg log" gives the following as the tip. So it appears I am current.
>>>
>>> changeset:   7651:2f3abc5ee6e8
>>> branch:      release-3-0-x
>>> tag:         tip
>>> parent:      7648:49014b68f297
>>> user:        John W. Eaton <jwe at octave.org>
>>> date:        Fri Mar 07 06:25:19 2008 -0500
>>> summary:     set axes layer property to "top"
>>>
>>> When I tried to build, it failed during "make check"
>>>
>>> [snip]
>>> make -f octMakefile check
>>> make -C test check
>>> ./build_sparse_tests.sh
>>> ../run-octave --norc --silent --no-history ./fntests.m .
>>>
>>> Integrated test scripts:
>>>
>>>   src/DLD-FUNCTIONS/bsxfun.cc ............................ PASS    
>>> 55/55
>>>   src/DLD-FUNCTIONS/cellfun.cc ........................... PASS    
>>> 31/31
>>>   src/DLD-FUNCTIONS/chol.cc .............................. PASS     
>>> 2/2
>>>   src/DLD-FUNCTIONS/conv2.cc ............................. PASS     
>>> 1/1
>>>   src/DLD-FUNCTIONS/dassl.cc ............................. PASS     
>>> 4/4
>>>   src/DLD-FUNCTIONS/dispatch.cc .......................... PASS    
>>> 13/13
>>>   src/DLD-FUNCTIONS/dmperm.cc ............................ PASS     
>>> 5/5
>>>   src/DLD-FUNCTIONS/fft.cc ............................... PASS    
>>> 13/13
>>>   src/DLD-FUNCTIONS/fsolve.cc ............................ PASS     
>>> 4/4
>>>   src/DLD-FUNCTIONS/lsode.cc ............................. PASS     
>>> 5/5
>>>   src/DLD-FUNCTIONS/luinc.cc ............................. PASS     
>>> 2/2
>>>   src/DLD-FUNCTIONS/matrix_type.cc ....................... PASS    
>>> 51/51
>>>   src/DLD-FUNCTIONS/qr.cc ................................panic:
>>> Segmentation fault -- stopping myself...
>>> make[2]: *** [check] Segmentation fault
>>> make[1]: *** [check] Error 2
>>> make: *** [check] Error 2
>>>
>>> Can some one confirm?
>>>
>>> Ben
>>


The seg-fault occurs for the test below. Adding "-fbounds-check" to  
FFLAGS had no effect.

  A = [0.620405 + 0.956953i  0.480013 + 0.048806i  0.402627 + 0.338171i;
       0.589077 + 0.658457i  0.013205 + 0.279323i  0.229284 + 0.721929i;
       0.092758 + 0.345687i  0.928679 + 0.241052i  0.764536 + 0.832406i;
       0.912098 + 0.721024i  0.049018 + 0.269452i  0.730029 + 0.796517i;
       0.112849 + 0.603871i  0.486352 + 0.142337i  0.355646 +  
0.151496i ];

  u = [0.20351 + 0.05401i;
       0.13141 + 0.43708i;
       0.29808 + 0.08789i;
       0.69821 + 0.38844i;
       0.74871 + 0.25821i ];

  v = [0.85839 + 0.29468i;
       0.20820 + 0.93090i;
       0.86184 + 0.34689i ];

  [Q,R] = qr(A);
  [Q,R] = qrupdate(Q,R,u,v);

I executed ./run-octave -g and ran fntests.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x00000000
0x8fe18b42 in __dyld_misaligned_stack_error ()

I placed the offending test into testqr.m, and ran it from within gdb.

octave:1> testqr
Reading symbols for shared libraries . done

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
#3  0x0017cac1 in zqr1up_ (m=@0xbfffa70c, n=@0xbfffa708,  
k=@0xbfffa704, q=0x31f68f0, r=0x31f6800, u=0x31f5710, v=0x31f54d0) at  
zqr1up.f:49
#4  0x01e2b072 in ComplexQR::update (this=0xbfffa7bc, u=@0xbfffa8d4,  
v=@0xbfffa8c0) at CmplxQR.cc:178
#5  0x02706b96 in Fqrupdate (args=@0x31f5c88) at qr.cc:499
(More stack frames follow...)
(gdb)

Regarding #2, a code snippet is below.

67 c apply rotation to rows of R if necessary
68        if (i <= n) then
69          call zrot(n+1-i,R(i,i),ldr,R(i+1,i),ldr,c,s)
70        end if

Does anyone see any thing suspicious?

I restarted the debug session and began with

(gdb) b zqrqhv_
Breakpoint 1 at 0x4f2b6: file zqrqhv.f, line 69.

I'm unfamiliar gdb, but this doesn't look correct to me. The first non- 
comment/non-declaration line in zqrqhv.f is 48.

47 c quick return if possible.
48       if (k <= 0) return

Is my gbd working properly? ... or do I need to spend time studying gdb?

Ben



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/bug-octave/attachments/20080311/fd8136ff/attachment-0001.html 


More information about the Bug-octave mailing list