|
From: Jeremy F. <je...@go...> - 2003-12-08 17:04:02
|
On Mon, 2003-12-08 at 07:57, Berthold Höllmann wrote: > ==32133== Process terminating with default action of signal 11 (SIGSEGV): dumping core > ==32133== at 0x46D73B98: ATL_dgemvT_a1_x1_b0_y1 (in /usr/software/fitools/linux/lib/libatlas_ifc.so.3.5.14) > ==32133== by 0x46D6825F: ATL_dgemv (in /usr/software/fitools/linux/lib/libatlas_ifc.so.3.5.14) > ==32133== > ==32133== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10583 from 10) > ==32133== malloc/free: in use at exit: 25570993 bytes in 3559 blocks. > ==32133== malloc/free: 52604 allocs, 49045 frees, 37158075 bytes allocated. > ==32133== For a detailed leak analysis, rerun with: --leak-check=yes > ==32133== For counts of detected errors, rerun with: -v > Segmentation fault > > > I've added the print statements for these last four lines into the > original LAPACK code, so I'm shure the segfault happens in the lapack > code. I extracted the imput parameters for my testcase and wrote a > little FORTRAN program just doing the call leading to the > segfault. This stripped down program runs successfull under > valgrind. > > Are there some tips how to track down the reason of the segfault in my > application? It's a little hard to tell without knowing what the instruction is at 0x46D73B98, but I'm guessing it's a GPF raised by an instruction like MOVNTDQ with an address which isn't 16-byte aligned. Try using --alignment=16. > Does this mean I have an unsupported syscall again? How do I find out > what it is? No, the core will always show Valgrind in a syscall (because it's always in the middle of a kill(getpid(), SIGSEGV). Instead, in this gdb try "x/i 0x46D73B98" to see what the faulting instruction is. That will help us work out what's really happening. J |