On 23/11/2019 20.30, Andreas Beckmann wrote:
> Control: affects 941933 + src:polymake
> Control: retitle -1 polymake: FTBFS with normaliz 3.8.1: segfaults during 
> tests
> 
> On 23/11/2019 10.45, Benjamin Lorenz wrote:
>> On 22/11/2019 22.06, Andreas Beckmann wrote:
>>> polymake FTBFS against perl 5.30:
> 
>> This was already reported and should be fixed with
>> https://bugs.debian.org/941933
>> but it seems that the builds need to be triggered again as the logs are
>> older than the normaliz 3.8.1+ds-1 upload.
> 
> OK, tried my first self-served give-backs ...
> 
> ... some architectures succeeed (arm64, s390x), some had tests failing
> with segmentation faults (amd64, i386, armhf, ppc64el), mips*el is
> still building.
> 
> https://buildd.debian.org/status/package.php?p=polymake&suite=unstable
> 
> Andreas
> 

tldr: please rebuild normaliz and then try polymake again.


This is very weird but after some digging through backtraces, headers
and bugzilla I am quite sure that this is caused by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267

The effect is that using the same std::deque template instantiation in
different libraries built with gcc 8 and gcc 9 can cause segfaults
because of an ABI incompatibility. In this case libppl.so.14.0.0 was
built with gcc 8 and libnormaliz with gcc 9 (9.2.1-12), both of them are
using std::deque<bool>. My build for polymake was with gcc 9 (9.2.1-19).

So I rebuilt ppl which to my surprise didn't help, but then I noticed
that debian already backported the fix for the gcc bug to gcc 9.2.1-16
(see
https://tracker.debian.org/news/1075824/accepted-gcc-9-921-16-source-into-unstable/).
This means that instead of ppl only normaliz needed to be rebuilt with
gcc >= 9.2.1-16.

Some logs from my experiments (rebuilding polymake is not necessary for
testing this, just switching out the other libraries):

### current normaliz build from unstable (ppl as well):

$ file /usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1

/usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1: ELF 64-bit LSB shared
object, x86-64, version 1 (GNU/Linux), dynamically linked,
BuildID[sha1]=49042b16a0c8fd0e5ecec9aa50e4fcf70842b8d5, stripped



$ objdump -s -j .comment
/usr/lib/debug/.build-id/49/042b16a0c8fd0e5ecec9aa50e4fcf70842b8d5.debug




Contents of section .comment:


 0000 4743433a 20284465 6269616e 20392e32  GCC: (Debian 9.2


 0010 2e312d31 32292039 2e322e31 20323031  .1-12) 9.2.1 201


 0020 39313032 3200                        91022.



lorenz@debian-unstable-amd64:~/polymake-3.2r4$ perl perl/polymake
--script run_testcases --applications polytope --examples
totally_dual_integral



*** Testing in application polytope ***





testing Examples:


 [ /functions/Optimization/totally_dual_integral ] 1Segmentation fault




### Installing my new local normaliz build:

# dpkg -i libnormaliz-dev_3.8.1+ds-1_amd64.deb
libnormaliz-dev-common_3.8.1+ds-1_all.deb
libnormaliz3_3.8.1+ds-1_amd64.deb libnormaliz3-dbgsym_3.8.1+ds-1_amd64.deb


$ file /usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1

/usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1: ELF 64-bit LSB shared
object, x86-64, version 1 (GNU/Linux), dynamically linked,
BuildID[sha1]=836dd385fe81deb4ca8b25dc9552a677ec24cc48, stripped

$ objdump -s -j .comment
/usr/lib/debug/.build-id/83/6dd385fe81deb4ca8b25dc9552a677ec24cc48.debug

Contents of section .comment:
 0000 4743433a 20284465 6269616e 20392e32  GCC: (Debian 9.2
 0010 2e312d31 39292039 2e322e31 20323031  .1-19) 9.2.1 201
 0020 39313130 3900                        91109.

$ perl perl/polymake --script run_testcases --applications polytope
--examples "totally_dual_integral"

*** Testing in application polytope ***

testing Examples:
 [ /functions/Optimization/totally_dual_integral ] 1 OK

*** Summary ***

*** All tests successful ***


For reference the top of the backtrace for the segfault with some weird
values for __n and __pos for the std::deque:

 [ /functions/Optimization/totally_dual_integral ] 1

Program received signal SIGSEGV, Segmentation fault.

0x00007ffff114972c in std::deque<bool, std::allocator<bool>
>::_M_fill_insert (this=0x7fffffffab88, __pos=<error reading variable:
Cannot access memory at address 0x14>, __n=140737488330560,
    __x=<error reading variable>) at /usr/include/c++/8/bits/deque.tcc:305
305     /usr/include/c++/8/bits/deque.tcc: No such file or directory.
(gdb) bt
#0  0x00007ffff114972c in std::deque<bool, std::allocator<bool>
>::_M_fill_insert (this=0x7fffffffab88, __pos=<error reading variable:
Cannot access memory at address 0x14>, __n=140737488330560,
    __x=<error reading variable>) at /usr/include/c++/8/bits/deque.tcc:305
#1  0x00007ffff0f110af in std::deque<bool, std::allocator<bool>
>::resize (this=0x7fffffffab88, __new_size=<optimized out>,
__x=<optimized out>) at /usr/include/c++/9/bits/stl_deque.h:757
#2  0x00007ffff0f14a77 in libnormaliz::Full_Cone<long long>::Full_Cone
(this=0x7fffffffa0f0, M=..., do_make_prime=<optimized out>) at
/usr/include/c++/9/bits/stl_vector.h:915
#3  0x00007ffff0e579cf in libnormaliz::Cone<__gmp_expr<__mpz_struct [1],
__mpz_struct [1]> >::compute_full_cone<long long>
(this=this@entry=0x7fffffffc380, ToCompute=...)
    at ../../source/libnormaliz/cone.cpp:2899

Benjamin

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to