Segmentation fault when built with CMake: alloc_mmap

[xsacha]

When built via CMake, I seem to get segmentation faults in alloc_mmap

Linux Core i7 Haswell

Backtrace

#0  0x0000555555560448 in alloc_mmap ()
#1  0x0000555555560681 in blas_memory_alloc ()
#2  0x0000555555556dc3 in gotoblas_init ()

Test app:

#include <cblas.h>
#include <stdio.h>

int main()
{
  int i=0;
  double A[6] = {1.0,2.0,1.0,-3.0,4.0,-1.0};
  double B[6] = {1.0,2.0,1.0,-3.0,4.0,-1.0};
  double C[9] = {.5,.5,.5,.5,.5,.5,.5,.5,.5};
  cblas_dgemm(CblasColMajor, CblasNoTrans, CblasTrans,3,3,2,1,A, 3, B, 3,2,C,3);

  for(i=0; i<9; i++)
    printf("%lf ", C[i]);
  printf("\n");
}

[brada4]

Works fine for me on a fresh build of 0.3.2
Can you get 't a a bt' i.e all backtrace, and the full crash text in GDB?

[martin-frbg]

xsacha can you provide more context please ? Is this current "develop" branch with default build options,
or something else ?

[xsacha]

It's version 0.3.2.

0x0000555555560448 in alloc_mmap ()
(gdb) t a a bt

Thread 1 (Thread 0x7ffff7fa9740 (LWP 22590)):
#0  0x0000555555560448 in alloc_mmap ()
#1  0x0000555555560681 in blas_memory_alloc ()
#2  0x0000555555556dc3 in gotoblas_init ()
#3  0x000055555556d61d in __libc_csu_init ()
#4  0x00007ffff6eeaffa in __libc_start_main () from /usr/lib/libc.so.6
#5  0x0000555555556e5a in _start ()

Library built with regular CMake, no extra options.

[martin-frbg]

Not reproducible here, perhaps it is a compiler or hardware problem on your end. Which compiler (and version) is it by the way ?

[xsacha]

Clang 6.0.1 on Arch Linux

[martin-frbg]

Weird. Suddenly I am seeing this on my system as well, so there seems to be some random component to it. (All I did in between was download the llvm6.0.1 source, which will have changed the memory footprint of the browser running on the same system)

Alloc Start ...
  Position -> 0
Allocation Start : 0
==26476== Invalid write of size 8
==26476==    at 0x40A3A9: alloc_mmap (memory.c:690)
==26476==    by 0x40A6F2: blas_memory_alloc (memory.c:1175)
==26476==    by 0x40AB76: gotoblas_memory_init (memory.c:1383)
==26476==    by 0x40ABE6: gotoblas_init (memory.c:1431)
==26476==    by 0x419E2C: __libc_csu_init (elf-init.c:88)
==26476==    by 0x5072674: (below main) (in /lib64/libc-2.22.so)
==26476==  Address 0x97f6000 is not stack'd, malloc'd or (recently) free'd

[martin-frbg]

Looks like a duplicate of #1705, so should be fixed in develop.

[xsacha]

Thanks. So much broken for me :( stuck on 0.3.0

[martin-frbg]

I certainly did not expect that level of fallout from #1618 et al., and drawn out over several weeks of surprises at that. I have now set the release date for 0.3.3 to next sunday to clear up this issue and the glibc-related tls hangs, and at least mitigate the "too many threads" problem some people are seeing since the memory.c rewrite.

[oon3m0oo]

Neither did I... this is most unfortunate. I'm working on completely removing the concept of too many threads right now.