Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Drew Parsons]

Kurt Kremitzki wrote:
Indeed, I agree that we should make sure we are building with Debian's 
Eigen.
I just pushed a new gmsh upload which adds it as a build dep and 
includes the

path in d/rules.


Thanks Kurt.


On 2021-02-14 14:22, Bernhard Übelacker wrote:


I still guess either all (might not just affect gmsh and dolphinx?)
have to build with the same alignment or
somehow allocation and deallocation have to take place
at the same side of the shared library boundary.



My bet is on the latter. But I might be wrong. We'll soon see if the new 
gmsh build helps, anyway.


Drew

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Kurt Kremitzki]

Hello,

On Sun, 14 Feb 2021 12:28:33 +0100 Drew Parsons  wrote:
> On 2021-02-14 12:00, Drew Parsons wrote:
> <-snip->
> But if we can add Bernhard's eigen path to the gmsh build then that will 
> remove one axis of inconsistency.
> 
> Drew
> 
> 

Indeed, I agree that we should make sure we are building with Debian's Eigen. 
I just pushed a new gmsh upload which adds it as a build dep and includes the 
path in d/rules.

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Am 14.02.21 um 11:37 schrieb Drew Parsons:
The dolfinx comments go on to say you might want to set 64 for 
user-compilation on AVX-512 systems. Would that AVX comment apply to 
your specific system?



Hello Drew,
my specific system is an amd64 kvm/qemu VM running at a AMD Ryzen 1700.
So as far as I see there is no avx512, just avx and avx 2 from lscpu.

But by using dpkg-buildpackage I was under the impression that the produced
binaries are for Debian baseline and not optimized for my CPU.
Also there is no -march visible when building with dpkg-buildpackage.


So from python side the abort happens here:
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3/dist-packages/gmsh.py", line 2256, in 
getElementProperties
api_wantedOrientations_, api_wantedOrientations_n_,
  File "/usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py", line 39, in 
name, dim, order, num_nodes, local_coords, num_first_order_nodes = 
model.mesh.getElementProperties(element_types[0])


I tested also to build libgmsh4 with this change:
-DEIGEN_INC:STRING="/usr/include/eigen3" \
-DEIGEN_MAX_ALIGN_BYTES=32

Then demo_gmsh.py gets over line 39 but still gives later
another python backtrace in line 62.


So from my limited point of view (as I don't really know much about these 
packages),
I still guess either all (might not just affect gmsh and dolphinx?)
have to build with the same alignment or
somehow allocation and deallocation have to take place
at the same side of the shared library boundary.

Kind regards,
Bernhard

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Drew Parsons]

On 2021-02-14 12:00, Drew Parsons wrote:


Curiously, my system now gives a completely different gmsh error (gmsh
4.7.1+ds1-2).
gmsh itself is broken:

$ gmsh
gmsh: symbol lookup error: /lib/x86_64-linux-gnu/libgmsh.so.4.7:
undefined symbol: _ZN4voro20voronoicell_neighborC1Ev


That problem is reported, Bug#982616.

As far as dolfinx and eigen alignment goes, dolfinx upstream has decided 
the best way to work around the problem is to remove eigen from 
dolfinx's public interfaces, 
https://github.com/FEniCS/dolfinx/issues/1381 (superseding 
https://github.com/FEniCS/dolfinx/issues/1277)


But Debian is now in freeze and those upstream changes in dolfinx are 
not fully completed and tested yet. bullseye might have to miss out.


But if we can add Bernhard's eigen path to the gmsh build then that will 
remove one axis of inconsistency.


Drew

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Drew Parsons]

On 2021-02-12 17:25, Bernhard Übelacker wrote:


# dpkg -l | grep -E "dolfinx|eigen3|gmsh" | LANG=C sort -k3b,3b -k2b,2b
ii  dolfinx-doc 2019.2.0~git20210130.c14cb0a-3 all  
Documentation and demo programs for DOLFIN
ii  libdolfinx-dev  2019.2.0~git20210130.c14cb0a-3 all  Shared 
links and header files for DOLFIN
ii  libeigen3-dev   3.3.9-2 all  lightweight C++ template 
library for linear algebra
ii  gmsh4.7.1+ds1-2   amd64Three-dimensional finite 
element mesh generator



Keep watch also on the version of python3-ffcx. I've been updating the 
fenics-x packages to work with basix. This is probably not what's 
affecting you though (it might affect testing users who pull packages 
from unstable).





$ python3 /usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py
double free or corruption (out)
[debian:89745] *** Process received signal ***



Curiously, my system now gives a completely different gmsh error (gmsh 
4.7.1+ds1-2).

gmsh itself is broken:

$ gmsh
gmsh: symbol lookup error: /lib/x86_64-linux-gnu/libgmsh.so.4.7: 
undefined symbol: _ZN4voro20voronoicell_neighborC1Ev

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Drew Parsons]

On 2021-02-13 23:51, Bernhard Übelacker wrote:


This flag is already in use, see 
https://salsa.debian.org/science-team/gmsh/-/

blob/master/debian/rules#L34




Hello everyone,
the ENABLE_SYSTEM_CONTRIB=1 seems not to be sufficient.

The build log shows this line:
-- Found Eigen
With this include given to c++:
-I/home/benutzer/source/libgmsh4/try2/gmsh-4.7.1+ds1/contrib/eigen

But in CMakeLists.txt we find these lines:
if(ENABLE_SYSTEM_CONTRIB)
find_path(EIGEN_INC "Eigen/Dense" HINTS eigen3)

...

Therefore it seems if it is not found in the system
and therefore it falls back to contrib.


Adding following to debian/rules:
-DEIGEN_INC:STRING="/usr/include/eigen3"

Would show this with an attempt to dpkg-buildpackage:
-- Found Eigen[system]
With this include given to c++:
-I/usr/include/eigen3



Thanks for this analysis, Bernard.  That will help gsmh use eigen 
consistent.





If its not desired to give the path directly maybe somehow retrieved 
by:

$ pkg-config --cflags eigen3
-I/usr/include/eigen3


Sensible to use pkg-config.
In fact we'd want to be more specific: `pkg-config --cflags-only-I 
eigen3`





But I built a package with that change, but the error remained.

So I rebuilt also dolfinx and saw that it gives to c++ this parameter:
"-DEIGEN_MAX_ALIGN_BYTES=32"
This define might change EIGEN_DEFAULT_ALIGN_BYTES,
and this controls how allocation is done inside
aligned_malloc/aligned_free.

Shouldn't either both have to override the default here
or both stay to the default?



A good question. I'm not certain what we need to do here, but I draw 
attention to the dolfinx comments in dolfinx/cpp/dolfinx/CMakeLists.txt:


# Note: The name EIGEN_MAX_ALIGN_BYTES is confusing. In practice, Eigen
# computes the ideal alignment based around -march.  If the ideal 
alignment is
# greater than EIGEN_MAX_ALIGN_BYTES, the ideal alignment is used. If 
the ideal

# alignment is less, then EIGEN_MAX_ALIGN_BYTES is used for alignment.

This suggests that dolfinx expects eigen to use a larger alignment than 
32 if the system's eigen supports it (so it is supposed to be safe to 
build dolfinx with the smaller value).


The dolfinx comments go on to say you might want to set 64 for 
user-compilation on AVX-512 systems. Would that AVX comment apply to 
your specific system?


Drew

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

This flag is already in use, see https://salsa.debian.org/science-team/gmsh/-/
blob/master/debian/rules#L34




Hello everyone,
the ENABLE_SYSTEM_CONTRIB=1 seems not to be sufficient.

The build log shows this line:
-- Found Eigen
With this include given to c++:
-I/home/benutzer/source/libgmsh4/try2/gmsh-4.7.1+ds1/contrib/eigen

But in CMakeLists.txt we find these lines:
if(ENABLE_SYSTEM_CONTRIB)
find_path(EIGEN_INC "Eigen/Dense" HINTS eigen3)
if(EIGEN_INC)
include_directories(${EIGEN_INC})
set_config_option(HAVE_EIGEN "Eigen[system]")
endif()
endif()
if(NOT HAVE_EIGEN)
include_directories(contrib/eigen)
set_config_option(HAVE_EIGEN "Eigen")
endif()

Therefore it seems if it is not found in the system
and therefore it falls back to contrib.


Adding following to debian/rules:
-DEIGEN_INC:STRING="/usr/include/eigen3"

Would show this with an attempt to dpkg-buildpackage:
-- Found Eigen[system]
With this include given to c++:
-I/usr/include/eigen3


If its not desired to give the path directly maybe somehow retrieved by:
$ pkg-config --cflags eigen3
-I/usr/include/eigen3




But I built a package with that change, but the error remained.

So I rebuilt also dolfinx and saw that it gives to c++ this parameter:
"-DEIGEN_MAX_ALIGN_BYTES=32"
This define might change EIGEN_DEFAULT_ALIGN_BYTES,
and this controls how allocation is done inside
aligned_malloc/aligned_free.

Shouldn't either both have to override the default here
or both stay to the default?


Kind regards,
Bernhard

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Am 12.02.21 um 16:06 schrieb Drew Parsons:


That could be the mismatch, if gmsh used its own copy of eigen different 
from 3.3.9.  Alternatively if libdolfinx-dev was built against an older 
version of eigen then it might make a discrepancy.


Dolfinx has just been updated in unstable. Bernhard, you could check if 
the rebuild for this new version fixes your problem.  But likely we'll 
want to apply Christophe's flag to the gmsh build.


Drew




Hello Drew,
I updated just all dolfinx packages to 2019.2.0~git20210130.c14cb0a-3.
(That drew updates for libbasix0 and libpetsc.)

But the fault does appear there too.

Kind regards,
Bernhard




# dpkg -l | grep -E "dolfinx|eigen3|gmsh" | LANG=C sort -k3b,3b -k2b,2b
ii  dolfinx-doc2019.2.0~git20210130.c14cb0a-3 all   
   Documentation and demo programs for DOLFIN
ii  libdolfinx-dev 2019.2.0~git20210130.c14cb0a-3 all   
   Shared links and header files for DOLFIN
ii  libeigen3-dev  3.3.9-2all   
   lightweight C++ template library for linear algebra
ii  gmsh   4.7.1+ds1-2amd64 
   Three-dimensional finite element mesh generator


$ python3 /usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py
double free or corruption (out)
[debian:89745] *** Process received signal ***

(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f5a72be4537 in __GI_abort () at abort.c:79
#2  0x7f5a72c3d768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f5a72d4be31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7f5a72c44a5a in malloc_printerr (str=str@entry=0x7f5a72d4e210 "double free 
or corruption (out)") at malloc.c:5347
#4  0x7f5a72c46088 in _int_free (av=0x7f5a72d7db80 , p=0x1df8070, 
have_lock=) at malloc.c:4314
#5  0x7f5a6304fad8 in Eigen::internal::aligned_free (ptr=) 
at ./contrib/eigen/Eigen/src/Core/util/Memory.h:177
#6  Eigen::internal::conditional_aligned_free (ptr=) at 
./contrib/eigen/Eigen/src/Core/util/Memory.h:230
#7  Eigen::internal::conditional_aligned_delete_auto (size=, ptr=) at ./contrib/eigen/Eigen/src/Core/util/Memory.h:416
#8  Eigen::DenseStorage::~DenseStorage (this=0x7ffc1434ab18, 
__in_chrg=) at ./contrib/eigen/Eigen/src/Core/DenseStorage.h:542

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Am 12.02.21 um 12:12 schrieb Drew Parsons:

Version mismatch could cause problems.

Bernhard, can you provide the versions of each of the packages you're 
reporting on

(dolfinx, eigen3, gmsh) ?


Hello,
these are the versions I have used in this test VM.

Would it be possible that libgmsh should use
the Memory.h below /usr instead of ./contrib ?

Kind regards,
Bernhard


# dpkg -l | grep -E "dolfinx|eigen3|gmsh" | LANG=C sort -k3b,3b -k2b,2b
ii  dolfinx-doc2019.2.0~git20201109.17bda9f-6 all   
   Documentation and demo programs for DOLFIN
ii  libdolfinx-dev 2019.2.0~git20201109.17bda9f-6 all   
   Shared links and header files for DOLFIN
ii  libdolfinx-real-dev:amd64  2019.2.0~git20201109.17bda9f-6 amd64 
   Shared links and header files for DOLFIN (real numbers)
ii  libdolfinx-real2019.2-dbgsym:amd64 2019.2.0~git20201109.17bda9f-6 amd64 
   debug symbols for libdolfinx-real2019.2
ii  libdolfinx-real2019.2:amd642019.2.0~git20201109.17bda9f-6 amd64 
   Shared libraries for DOLFIN
ii  python3-dolfinx-real   2019.2.0~git20201109.17bda9f-6 amd64 
   Python interface for DOLFIN (Python 3)
ii  python3-dolfinx:amd64  2019.2.0~git20201109.17bda9f-6 amd64 
   Python interface for DOLFIN (Python 3)
ii  libeigen3-dev  3.3.9-2all   
   lightweight C++ template library for linear algebra
ii  gmsh   4.7.1+ds1-2amd64 
   Three-dimensional finite element mesh generator
ii  gmsh-doc   4.7.1+ds1-2all   
   Three-dimensional finite element mesh generator documentation
ii  libgmsh4-dbgsym:amd64  4.7.1+ds1-2amd64 
   debug symbols for libgmsh4
ii  libgmsh4:amd64 4.7.1+ds1-2amd64 
   Three-dimensional finite element mesh generator shared library
ii  python3-gmsh   4.7.1+ds1-2all   
   Three-dimensional finite element mesh generator Python 3 wrapper

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Kurt Kremitzki]

Hello all,

On Friday, February 12, 2021 8:18:02 AM CST Christophe Geuzaine wrote:
> > On 12 Feb 2021, at 14:24, Bernhard Übelacker 
> > wrote:
> > 
> > Am 12.02.21 um 12:12 schrieb Drew Parsons:
> >> Version mismatch could cause problems.
> >> Bernhard, can you provide the versions of each of the packages you're
> >> reporting on (dolfinx, eigen3, gmsh) ?
> > 
> > Hello,
> > these are the versions I have used in this test VM.
> > 
> > Would it be possible that libgmsh should use
> > the Memory.h below /usr instead of ./contrib ?
> 
> You could configure Gmsh with "cmake -DENABLE_SYSTEM_CONTRIB=1", which will
> instruct Gmsh to use "system" versions of the contrib packages if they are
> available.
> 
> Christophe
> 

This flag is already in use, see https://salsa.debian.org/science-team/gmsh/-/
blob/master/debian/rules#L34

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Drew Parsons]

On 2021-02-12 15:18, Christophe Geuzaine wrote:
On 12 Feb 2021, at 14:24, Bernhard Übelacker  
wrote:


Am 12.02.21 um 12:12 schrieb Drew Parsons:

Version mismatch could cause problems.
Bernhard, can you provide the versions of each of the packages you're 
reporting on

(dolfinx, eigen3, gmsh) ?


Hello,
these are the versions I have used in this test VM.

Would it be possible that libgmsh should use
the Memory.h below /usr instead of ./contrib ?


You could configure Gmsh with "cmake -DENABLE_SYSTEM_CONTRIB=1", which
will instruct Gmsh to use "system" versions of the contrib packages if
they are available.



That is almost certainly a good idea, thanks Christophe.





# dpkg -l | grep -E "dolfinx|eigen3|gmsh" | LANG=C sort -k3b,3b 
-k2b,2b
ii  dolfinx-doc
2019.2.0~git20201109.17bda9f-6 all  Documentation and demo 
programs for DOLFIN
ii  libdolfinx-dev 
2019.2.0~git20201109.17bda9f-6 all  Shared links and header 
files for DOLFIN
ii  libeigen3-dev  3.3.9-2 
   all  lightweight C++ template library for linear algebra
ii  gmsh   4.7.1+ds1-2 
   amd64Three-dimensional finite element mesh generator



That could be the mismatch, if gmsh used its own copy of eigen different 
from 3.3.9.  Alternatively if libdolfinx-dev was built against an older 
version of eigen then it might make a discrepancy.


Dolfinx has just been updated in unstable. Bernhard, you could check if 
the rebuild for this new version fixes your problem.  But likely we'll 
want to apply Christophe's flag to the gmsh build.


Drew

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at this issue and I saw
that the allocation takes place inside libdolfinx_real.so.2019.2,
inside /usr/include/eigen3/Eigen/src/Core/util/Memory.h.

But the failing free is done in libgmsh.so.4.7,
which uses ./contrib/eigen/Eigen/src/Core/util/Memory.h.

There seem to be a disagreement if the allocator is
already returning aligned addresses,
therefore one uses handmade_aligned_malloc,
but the free uses directly std::free() instead handmade_aligned_free.

Might this cause the issue?

Kind regards,
Bernhard


Allocation:
(rr) bt
#0  0x7f2860acc19d in __GI___libc_malloc (bytes=) at 
malloc.c:3082
#1  0x7f285e7d2bdb in Eigen::internal::handmade_aligned_malloc 
(size=16) at /usr/include/eigen3/Eigen/src/Core/util/Memory.h:88
#2  Eigen::internal::aligned_malloc (size=16) at 
/usr/include/eigen3/Eigen/src/Core/util/Memory.h:164
#3  Eigen::internal::conditional_aligned_malloc (size=16) at 
/usr/include/eigen3/Eigen/src/Core/util/Memory.h:214
#4  Eigen::internal::conditional_aligned_new_auto (size=4) at 
/usr/include/eigen3/Eigen/src/Core/util/Memory.h:374
#5  Eigen::DenseStorage::resize (rows=4, size=4, 
this=0x7ffe74198f58) at /usr/include/eigen3/Eigen/src/Core/DenseStorage.h:557
...

Free:
(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f2860a67537 in __GI_abort () at abort.c:79
#2  0x7f2860ac0768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f2860bcee31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7f2860ac7a5a in malloc_printerr (str=str@entry=0x7f2860bd1210 "double 
free or corruption (out)") at malloc.c:5347
#4  0x7f2860ac9088 in _int_free (av=0x7f2860c00b80 , p=0x23cb2f0, 
have_lock=) at malloc.c:4314
#5  0x7f2851183ad8 in Eigen::internal::aligned_free (ptr=) at ./contrib/eigen/Eigen/src/Core/util/Memory.h:177
#6  Eigen::internal::conditional_aligned_free (ptr=) 
at ./contrib/eigen/Eigen/src/Core/util/Memory.h:230
#7  Eigen::internal::conditional_aligned_delete_auto (size=, ptr=) at ./contrib/eigen/Eigen/src/Core/util/Memory.h:416
#8  Eigen::DenseStorage::~DenseStorage (this=0x7ffe74198f58, 
__in_chrg=) at ./contrib/eigen/Eigen/src/Core/DenseStorage.h:542
...


# Bullseye amd64 qemu VM 2021-02-11


apt update
apt dist-upgrade


apt install systemd-coredump valgrind mc rr gdb dolfinx-doc python3-gmsh
apt build-dep libc6
apt install libgmsh4-dbgsym libdolfinx-real2019.2-dbgsym

echo 1 > /proc/sys/kernel/perf_event_paranoid






mkdir /home/benutzer/source/libc6/orig -p
cd /home/benutzer/source/libc6/orig
apt source libc6
cd

mkdir /home/benutzer/source/libgmsh4/orig -p
cd /home/benutzer/source/libgmsh4/orig
apt source libgmsh4
cd







$ rr record python3 /usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/python3-0'.
double free or corruption (out)

Loguru caught a signal: SIGABRT
Abgebrochen



$ rr replay python3-0
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python3.9...
(No debugging symbols found in /usr/bin/python3.9)
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
Remote debugging using 127.0.0.1:22636
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from 
/usr/lib/debug/.build-id/5b/e47e85c990f390b0dccb6ca9dc3e70f410dc6a.debug...
0x7f2860de8090 in _start () from /lib64/ld-linux-x86-64.so.2
(rr) directory /home/benutzer/source/libc6/orig/glibc-2.31/malloc
Source directories searched: 
/home/benutzer/source/libc6/orig/glibc-2.31/malloc:$cdir:$cwd
(rr) directory /home/benutzer/source/libgmsh4/orig/gmsh-4.7.1+ds1
Source directories searched: 
/home/benutzer/source/libgmsh4/orig/gmsh-4.7.1+ds1:/home/benutzer/source/libc6/orig/glibc-2.31/malloc:$cdir:$cwd
(rr) set width 0
(rr) set pagination off
(rr) cont
Continuing.
double free or corruption (out)
[New Thread 10825.10830]
[New Thread 10825.10831]

Thread 1 received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50return ret;
(rr) when
Current event: 16792
(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Christophe Geuzaine]

> On 12 Feb 2021, at 14:24, Bernhard Übelacker  wrote:
> 
> Am 12.02.21 um 12:12 schrieb Drew Parsons:
>> Version mismatch could cause problems.
>> Bernhard, can you provide the versions of each of the packages you're 
>> reporting on
>> (dolfinx, eigen3, gmsh) ?
> 
> Hello,
> these are the versions I have used in this test VM.
> 
> Would it be possible that libgmsh should use
> the Memory.h below /usr instead of ./contrib ?

You could configure Gmsh with "cmake -DENABLE_SYSTEM_CONTRIB=1", which will 
instruct Gmsh to use "system" versions of the contrib packages if they are 
available.

Christophe


> 
> Kind regards,
> Bernhard
> 
> 
> # dpkg -l | grep -E "dolfinx|eigen3|gmsh" | LANG=C sort -k3b,3b -k2b,2b
> ii  dolfinx-doc2019.2.0~git20201109.17bda9f-6 all 
>  Documentation and demo programs for DOLFIN
> ii  libdolfinx-dev 2019.2.0~git20201109.17bda9f-6 all 
>  Shared links and header files for DOLFIN
> ii  libdolfinx-real-dev:amd64  2019.2.0~git20201109.17bda9f-6 
> amd64Shared links and header files for DOLFIN (real numbers)
> ii  libdolfinx-real2019.2-dbgsym:amd64 2019.2.0~git20201109.17bda9f-6 
> amd64debug symbols for libdolfinx-real2019.2
> ii  libdolfinx-real2019.2:amd642019.2.0~git20201109.17bda9f-6 
> amd64Shared libraries for DOLFIN
> ii  python3-dolfinx-real   2019.2.0~git20201109.17bda9f-6 
> amd64Python interface for DOLFIN (Python 3)
> ii  python3-dolfinx:amd64  2019.2.0~git20201109.17bda9f-6 
> amd64Python interface for DOLFIN (Python 3)
> ii  libeigen3-dev  3.3.9-2all 
>  lightweight C++ template library for linear algebra
> ii  gmsh   4.7.1+ds1-2
> amd64Three-dimensional finite element mesh generator
> ii  gmsh-doc   4.7.1+ds1-2all 
>  Three-dimensional finite element mesh generator documentation
> ii  libgmsh4-dbgsym:amd64  4.7.1+ds1-2
> amd64debug symbols for libgmsh4
> ii  libgmsh4:amd64 4.7.1+ds1-2
> amd64Three-dimensional finite element mesh generator shared library
> ii  python3-gmsh   4.7.1+ds1-2all 
>  Three-dimensional finite element mesh generator Python 3 wrapper
> 

— 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://people.montefiore.uliege.be/geuzaine

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Drew Parsons]

On 2021-02-12 11:37, Bernhard Übelacker wrote:

Dear Maintainer,
I tried to have a look at this issue and I saw
that the allocation takes place inside libdolfinx_real.so.2019.2,
inside /usr/include/eigen3/Eigen/src/Core/util/Memory.h.

But the failing free is done in libgmsh.so.4.7,
which uses ./contrib/eigen/Eigen/src/Core/util/Memory.h.

There seem to be a disagreement if the allocator is
already returning aligned addresses,
therefore one uses handmade_aligned_malloc,
but the free uses directly std::free() instead handmade_aligned_free.

Might this cause the issue?



Version mismatch could cause problems.

Bernhard, can you provide the versions of each of the packages you're 
reporting on

(dolfinx, eigen3, gmsh) ?


Drew

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Drew Parsons]

dolfinx developers appear to be discussing the issue at 
https://github.com/FEniCS/dolfinx/issues/1277

referring to alignment issues with eigen.

Not clear yet where the underlying fault is.

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Drew Parsons]

Package: libgmsh4
Version: 4.7.1+ds1-2
Severity: normal
Control: affects -1 dolfinx-doc

dolfinx-doc provides some python demos for dolfinx which are tested by
debci. One of the demos tests gmsh. You can see it (demo_gmsh.py) has
been failing in debci, e.g.
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dolfinx/9989408/log.gz
with the error message:

  double free or corruption (out)
  
  Loguru caught a signal: SIGABRT


The SIGABRT is reproducible manually
  # apt-get install python3-dolfinx dolfinx-doc
  $ python3 /usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py


gdb gives a detailed backtrace which suggests the problem might come
not from dolfinx but from libgmsh.so.4 in polynomialBasis, or possibly
from eigen in Eigen::internal::compute_inverse

$ gdb python3
(gdb) run /usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py
...
double free or corruption (out)

Thread 1 "python3" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77c2a537 in __GI_abort () at abort.c:79
#2  0x77c83768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x77d91e31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x77c8aa5a in malloc_printerr (str=str@entry=0x77d94210 "double 
free or corruption (out)") at malloc.c:5347
#4  0x77c8c088 in _int_free (av=0x77dc3b80 , 
p=0x3df9b90, have_lock=) at malloc.c:4314
#5  0x7fff982dfad8 in 
Eigen::internal::compute_inverse, 0, Eigen::Stride<0, 0> >, Eigen::Map, 0, Eigen::Stride<0, 0> >, -1>::run(Eigen::Map, 0, Eigen::Stride<0, 0> > const&, 
Eigen::Map, 0, Eigen::Stride<0, 0> >&) 
()
   from /lib/x86_64-linux-gnu/libgmsh.so.4.7
#6  0x7fff982e574f in polynomialBasis::polynomialBasis(int) () from 
/lib/x86_64-linux-gnu/libgmsh.so.4.7
#7  0x7fff9824dbca in gmsh::model::mesh::getElementProperties(int, 
std::__cxx11::basic_string, std::allocator 
>&, int&, int&, int&, std::vector >&, int&) () 
from /lib/x86_64-linux-gnu/libgmsh.so.4.7
#8  0x7fff98e07640 in gmshModelMeshGetElementProperties () from 
/lib/x86_64-linux-gnu/libgmsh.so.4.7
#9  0x77fa1d1d in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#10 0x77fa1289 in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#11 0x7fffb91ce360 in _call_function_pointer (argtypecount=, 
argcount=9, resmem=0x7fffd7a0, restype=, atypes=, avalues=, 
pProc=0x7fff98e075c0 , flags=4353) at 
./Modules/_ctypes/callproc.c:920
#12 _ctypes_callproc (pProc=0x7fff98e075c0 , 
argtuple=, flags=4353, argtypes=, 
restype=<_ctypes.PyCSimpleType at remote 0xbfdaa0>, checker=0x0)
at ./Modules/_ctypes/callproc.c:1263
#13 0x7fffb91c48d8 in PyCFuncPtr_call (self=, 
inargs=, kwds=) at 
./Modules/_ctypes/_ctypes.c:4201
#14 0x0051db9b in _PyObject_MakeTpCall (tstate=0x9632b0, 
callable=<_FuncPtr(__name__='gmshModelMeshGetElementProperties') at remote 
0x7fffb83f41c0>, args=, nargs=, 
keywords=) at ../Objects/call.c:191
#15 0x005178a1 in _PyObject_VectorcallTstate (kwnames=0x0, 
nargsf=, args=0x4562720, 
callable=<_FuncPtr(__name__='gmshModelMeshGetElementProperties') at remote 
0x7fffb83f41c0>, 
tstate=0x9632b0) at ../Include/cpython/abstract.h:116
#16 _PyObject_VectorcallTstate (kwnames=0x0, nargsf=, 
args=0x4562720, 
callable=<_FuncPtr(__name__='gmshModelMeshGetElementProperties') at remote 
0x7fffb83f41c0>, tstate=0x9632b0)
at ../Include/cpython/abstract.h:103
#17 PyObject_Vectorcall (kwnames=0x0, nargsf=, args=0x4562720, 
callable=<_FuncPtr(__name__='gmshModelMeshGetElementProperties') at remote 
0x7fffb83f41c0>) at ../Include/cpython/abstract.h:127
#18 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x9632b0) at ../Python/ceval.c:5072
#19 _PyEval_EvalFrameDefault (tstate=, f=, 
throwflag=) at ../Python/ceval.c:3487
#20 0x00528ee3 in _PyEval_EvalFrame (throwflag=0, 
f=Frame 0x4562560, for file /usr/lib/python3/dist-packages/gmsh.py, line 
2256, in getElementProperties (elementType=, api_elementName_=, 
api_dim_=, api_order_=, api_numNodes_=, 
api_localNodeCoord_=, 
api_localNodeCoord_n_=, 
api_numPrimaryNodes_=, ierr=), tstate=0x9632b0) at ../Include/internal/pycore_ceval.h:40
#21 function_code_fastcall (globals=, nargs=1, args=, co=, tstate=0x9632b0) at ../Objects/call.c:330
#22 _PyFunction_Vectorcall (func=, stack=, 
nargsf=, kwnames=) at ../Objects/call.c:367
#23 0x0051721b in _PyObject_VectorcallTstate (kwnames=0x0, 
nargsf=, args=0x9be108, callable=, tstate=0x9632b0) at ../Include/cpython/abstract.h:118
#24 PyObject_Vectorcall (kwnames=0x0, nargsf=, args=0x9be108, 
callable=) at 
../Include/cpython/abstract.h:127
#25 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x9632b0) at ../Python/ceval.c:5072
#26 _PyEval_EvalFrameDefault (tstate=, f=, 
throwflag=) at ../Python/ceval.c:3487
#27 0x0051