Segfault in dpotrf

[masuday]

Hi all,
I met the segfault in dpotrf when the order of matrix was very large (50000 or more). The following is the message:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

0 0x2B3D879F5E77

1 0x2B3D879F6444

2 0x2B3D883F191F

3 0x40EAB8 in dgemm_kernel at dgemm_kernel_4x8_sandy.S:416

The basic information is:

• Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (SandyBridge)
• Linux x86_64; gcc/gfortran 4.7.2;
• OpenBLAS 0.2.8 compiled with BINARY=64, DEBUG=1

The problem was not found when the OpenBLAS compiled with NO_LAPACK=1 and the reference LAPACK were used.

A sample program is:

program test
   implicit none
   integer,parameter :: m=50000
   real(8),allocatable :: A(:,:)
   integer :: i,j,info
   external DPOTRF,DPOTRI

   allocate(A(m,m))
   A = 0.0
   do j=1,m
      A(j,j) = 2.0
      do i=j+1,m
         A(i,j) = 1.0
      end do
   end do

   call DPOTRF('L',m,A,m,info) 
   call DPOTRI('L',m,A,m,info) 

   deallocate(A)
   stop
end program test

Thanks,
Masuday

[martin-frbg]

Could you retest with the currrent release candidate for 0.2.9 ? I ran your test on a Haswell machine,
but with OpenBLAS (0.2.9.rc1) specifically configured for SandyBridge and it did not fail here. (Took 18.7 GB of RAM btw)

[masuday]

Hi martin-frbg,
Thank you for your response. I have tried additional experiments using the OpenBLAS v0.2.9rc2 compiled with different options. I changed the environment because of conducting flexible tests.

• Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (SandyBridge; Hyper-threading ON)
• Linux 2.6.32-431.5.1.el6.x86_64
• gcc/gfortran 4.7.3
• 32GB RAM

Basic options for compiling OpenBLAS were BINARY=64 and DEBUG = 1. All options were specified in Makefile.rule. Here are the results.

Target	Additional options	Result
SANDYBRIDGE	(none)	SIGSEGV
	NUM_THREADS=4	SIGSEGV
	NUM_THREADS=2	SIGSEGV
	USE_THREAD=0	OK
NEHALEM	(none)	SIGSEGV
	NUM_THREADS=4	SIGSEGV
	NUM_THREADS=2	SIGSEGV
	USE_THREAD=0	OK

I also found that DPOTRF worked with n<=31985 but failed with n>31985 when TARGET=SANDYBRIDGE. The threshold could be different when TARGET=NEHALEM. I just checked whether the program crashed with SIGSEGV or not (i.e. I didn't check the resulting values).

I will try the same tests without hyper-threading.

Thanks,
Masuday

[masuday]

Without hyper-threading, the same results (SIGSEGV) were observed, using the OpenBLAS configured for SandyBridge and Nehalem (4 threads).

[martin-frbg]

Sorry, I forgot that my test setting used USE_THREAD=0 (and USE_OPENMP=1) as we use OpenBLAS in the context of a program that is itself multithreaded. With USE_THREAD=1, I can indeed reproduce your crash, with gdb pointing to
dgemm_kernel () at ../kernel/x86_64/dgemm_kernel_4x8_sandy.S:416
416 LD_DY 0*SIZE(ptrbb), yvec2;

[martin-frbg]

Same options, but building for Haswell results in
Program received signal SIGSEGV, Segmentation fault.
dgemm_otcopy (m=m@entry=256, n=n@entry=4, a=a@entry=0x7ffb3f609810, lda=lda@entry=50000, b=b@entry=0x7ffff418a000)
at ../kernel/x86_64/../generic/gemm_tcopy_4.c:99
99 *(b_offset1 + 0) = ctemp1;
(gdb) print ctemp1
$1 = 0.70710678118654746
(gdb) print b_offset1
$2 = (double *) 0x7ffff418a000
(gdb) print *b_offset1
Cannot access memory at address 0x7ffff418a000