Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
Libreoffice migrated to testing. I am closing the bug. Next time the symbols of the new version will be checked precisely. Thanks all for discussion. Regards Anton 2017-09-08 23:17 GMT+02:00 Rene Engelhard : > On Fri, Sep 08, 2017 at 07:37:03PM +0200, Francesco Poli wrote: >> Will libreoffice/1:5.4.1-1 (currently in unstable and testing) break, >> if I upgrade coinor-libcoinutils3v5 from version 2.9.15-4 to version >> 2.10.14+repack1-1 ? > > The fix for LO is: rebuild coinmp. It works without rebuilding LO. > > That said, you probably didn't even check libreoffice/1:5.4.1-1s dependencies > sincce to go very very sure for partial upgrades it depends on the new, > rebuilt coinmp (and because coinutils didn't bump soname or so) on the > matching > coinutils. > > So LO will work. > > Regards, > > Rene
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
On Fri, 8 Sep 2017 23:17:49 +0200 Rene Engelhard wrote: > On Fri, Sep 08, 2017 at 07:37:03PM +0200, Francesco Poli wrote: > > Will libreoffice/1:5.4.1-1 (currently in unstable and testing) break, > > if I upgrade coinor-libcoinutils3v5 from version 2.9.15-4 to version > > 2.10.14+repack1-1 ? > > The fix for LO is: rebuild coinmp. It works without rebuilding LO. > > That said, you probably didn't even check libreoffice/1:5.4.1-1s dependencies > sincce to go very very sure for partial upgrades it depends on the new, > rebuilt coinmp (and because coinutils didn't bump soname or so) on the > matching > coinutils. > > So LO will work. OK, thanks for the clarification! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp357YY8T80f.pgp Description: PGP signature
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
On Fri, Sep 08, 2017 at 07:37:03PM +0200, Francesco Poli wrote: > Will libreoffice/1:5.4.1-1 (currently in unstable and testing) break, > if I upgrade coinor-libcoinutils3v5 from version 2.9.15-4 to version > 2.10.14+repack1-1 ? The fix for LO is: rebuild coinmp. It works without rebuilding LO. That said, you probably didn't even check libreoffice/1:5.4.1-1s dependencies sincce to go very very sure for partial upgrades it depends on the new, rebuilt coinmp (and because coinutils didn't bump soname or so) on the matching coinutils. So LO will work. Regards, Rene
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
On Mon, 28 Aug 2017 20:39:29 +0100 James Cowgill wrote: > Hi, > > On 28/08/17 19:57, Anton Gladky wrote: > > Thanks all for discussion, explanations and investigations! > > > > @Rene, I propose to close this bug or to wait till upload of libreoffice. > > > > Next time, when the new coinutils version comes, I will let you know > > and coinmp should be tested against the new coinutils. Then it should > > probably be uploaded into the sid restricting in BD the minimal coinutils > > to guarantee the ABI compatibility like it done for all other dependent > > packages [1]. What do you think? > > > > [1] > > https://anonscm.debian.org/cgit/debian-science/packages/coinor-cbc.git/tree/debian/control#n8 > > If there is an ABI break, you must rename the package. Trying to > restrict the build-dependencies will have no effect on the dependencies > at runtime which is where the ABI actually matters. > Hello, I am a user who pinned this package to version 2.9.15-4, because of this bug. I took a look at the bug log, but I am afraid I did not understand the conclusion: is there an actual ABI break or is it just some weak symbols appearing/disappearing depending on different inlining decisions taken by different compiler versions? Will libreoffice/1:5.4.1-1 (currently in unstable and testing) break, if I upgrade coinor-libcoinutils3v5 from version 2.9.15-4 to version 2.10.14+repack1-1 ? Should this bug report be closed or kept open? Could you please clarify? Thanks for your time and patience! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp86Vyxpp6qf.pgp Description: PGP signature
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
Hi, On 28/08/17 19:57, Anton Gladky wrote: > Thanks all for discussion, explanations and investigations! > > @Rene, I propose to close this bug or to wait till upload of libreoffice. > > Next time, when the new coinutils version comes, I will let you know > and coinmp should be tested against the new coinutils. Then it should > probably be uploaded into the sid restricting in BD the minimal coinutils > to guarantee the ABI compatibility like it done for all other dependent > packages [1]. What do you think? > > [1] > https://anonscm.debian.org/cgit/debian-science/packages/coinor-cbc.git/tree/debian/control#n8 If there is an ABI break, you must rename the package. Trying to restrict the build-dependencies will have no effect on the dependencies at runtime which is where the ABI actually matters. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
Thanks all for discussion, explanations and investigations! @Rene, I propose to close this bug or to wait till upload of libreoffice. Next time, when the new coinutils version comes, I will let you know and coinmp should be tested against the new coinutils. Then it should probably be uploaded into the sid restricting in BD the minimal coinutils to guarantee the ABI compatibility like it done for all other dependent packages [1]. What do you think? [1] https://anonscm.debian.org/cgit/debian-science/packages/coinor-cbc.git/tree/debian/control#n8 Best regards Anton 2017-08-28 17:56 GMT+02:00 James Cowgill : > These appear to be the 4 symbols which have disappeared after compiling > with GCC-7: > > 469: 000cce10 430 FUNCWEAK DEFAULT 12 > _ZNK16CoinPackedMatrix14getVectorFirstEi > 614: 000ccfc0 437 FUNCWEAK DEFAULT 12 > _ZNK16CoinPackedMatrix13getVectorLastEi > 1119: 000fc710 120 FUNCWEAK DEFAULT 12 > _Z26presolve_delete_from_majoriiPKiPiS1_Pd > 1198: 00043f80 566 FUNCWEAK DEFAULT 12 > _Z9CoinFillNItEvPT_iS0_ > > As you can see all of these symbols are declared as weak. GCC will often > do this for inline functions which it has decided not to inline for some > reason. To satisfy the ODR, GCC will export all these symbols as weak > from any object (including executables) which use them so that the same > function is used throughout the entire application. Because consumers > are supposed to generate their own versions of these functions, they do > not form a part of the ABI and can safely be removed. In this case, > GCC-7 simply decided that these functions should be inlined and > therefore didn't generate symbols for them. > > I think it's more likely these ABI issues are caused by changes in the > class layout (but I have not investigated this much). You can see a few > cases of new fields being added if you diff the headers from the old and > new packages. Generally, any issues with symbols would be found by the > dynamic linker before an application has a chance to segfault. > > Thanks, > James >
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
Hi, On 28/08/17 13:58, Mattia Rizzolo wrote: > On Sun, 27 Aug 2017, 8:37 p.m. Anton Gladky wrote: > >> Hi Mattia, >> >> thanks for the tip! I have recompiled both libs with the same >> current gcc-7.2. And it looks like there are no dropped symbols >> (see file old-gcc7_new-gcc7.diff in attachment). >> >> But if I compare new so-file with the one shipped with Stretch >> (compiled with gcc6) >> the diff contains some missing symbols (see file old-gcc6_new-gcc7.diff). >> > > Oh! That's interesting... > > What is the best practice for such kind of libs? Provide symbol-files? > > Not sure. I'd suggest to try to ask to -mentors@ or -devel@, or perhaps to > James Cowgirl (CCed now) who helped with gcc-7 related stuff :) These appear to be the 4 symbols which have disappeared after compiling with GCC-7: 469: 000cce10 430 FUNCWEAK DEFAULT 12 _ZNK16CoinPackedMatrix14getVectorFirstEi 614: 000ccfc0 437 FUNCWEAK DEFAULT 12 _ZNK16CoinPackedMatrix13getVectorLastEi 1119: 000fc710 120 FUNCWEAK DEFAULT 12 _Z26presolve_delete_from_majoriiPKiPiS1_Pd 1198: 00043f80 566 FUNCWEAK DEFAULT 12 _Z9CoinFillNItEvPT_iS0_ As you can see all of these symbols are declared as weak. GCC will often do this for inline functions which it has decided not to inline for some reason. To satisfy the ODR, GCC will export all these symbols as weak from any object (including executables) which use them so that the same function is used throughout the entire application. Because consumers are supposed to generate their own versions of these functions, they do not form a part of the ABI and can safely be removed. In this case, GCC-7 simply decided that these functions should be inlined and therefore didn't generate symbols for them. I think it's more likely these ABI issues are caused by changes in the class layout (but I have not investigated this much). You can see a few cases of new fields being added if you diff the headers from the old and new packages. Generally, any issues with symbols would be found by the dynamic linker before an application has a chance to segfault. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
On Sun, 27 Aug 2017, 8:37 p.m. Anton Gladky wrote: > Hi Mattia, > > thanks for the tip! I have recompiled both libs with the same > current gcc-7.2. And it looks like there are no dropped symbols > (see file old-gcc7_new-gcc7.diff in attachment). > > But if I compare new so-file with the one shipped with Stretch > (compiled with gcc6) > the diff contains some missing symbols (see file old-gcc6_new-gcc7.diff). > Oh! That's interesting... What is the best practice for such kind of libs? Provide symbol-files? > Not sure. I'd suggest to try to ask to -mentors@ or -devel@, or perhaps to James Cowgirl (CCed now) who helped with gcc-7 related stuff :) Thank you > > PS I have generated the symbols with the command: > readelf -Ws libCoinUtils.so | awk '{print $8}' > Tbh, in general I'd use dpkg-gensymbols, but well, I think it's the same.
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
Hi Mattia, thanks for the tip! I have recompiled both libs with the same current gcc-7.2. And it looks like there are no dropped symbols (see file old-gcc7_new-gcc7.diff in attachment). But if I compare new so-file with the one shipped with Stretch (compiled with gcc6) the diff contains some missing symbols (see file old-gcc6_new-gcc7.diff). What is the best practice for such kind of libs? Provide symbol-files? Thank you PS I have generated the symbols with the command: readelf -Ws libCoinUtils.so | awk '{print $8}' Anton 2017-08-27 18:04 GMT+02:00 Mattia Rizzolo : > On Sun, Aug 27, 2017 at 03:16:46PM +0200, Anton Gladky wrote: >> > Still I believe that this should be "correctly" fixed. >> >> You mean to increase so-version even if upstream does not do it and >> to start the normal transition process? I think it is possible. > > That's actually your only option. > Could someone check the symbols of the library before and after the > upload and check whether some have been dropped? If there are, not > bumping SONAME is a bug upstream should deal with by doing another > release and doing so (and failing so, in Debian you should at the very > least rename the binary package (doing somethng alike to the v5 thing > done for libstdc++5)). > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > more about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- diff --git a/symb_old_gcc6 b/symb_new_gcc7 index b2c7fe0..81b10dc 100644 --- a/symb_old_gcc6 +++ b/symb_new_gcc7 @@ -9,7 +9,6 @@ BZ2_bzWrite BZ2_bzWriteClose BZ2_bzWriteOpen calloc@GLIBC_2.2.5 -ceil@GLIBC_2.2.5 c_ekkbtrn c_ekkbtrn_ipivrw c_ekketsj @@ -70,7 +69,6 @@ isalnum@GLIBC_2.2.5 isalpha@GLIBC_2.2.5 _ITM_deregisterTMCloneTable _ITM_registerTMCloneTable -_Jv_RegisterClasses log10@GLIBC_2.2.5 log@GLIBC_2.2.5 malloc@GLIBC_2.2.5 @@ -79,6 +77,7 @@ __memcpy_chk@GLIBC_2.3.4 memcpy@GLIBC_2.14 memmove@GLIBC_2.2.5 memset@GLIBC_2.2.5 +modf@GLIBC_2.2.5 pow@GLIBC_2.2.5 __printf_chk@GLIBC_2.3.4 putchar@GLIBC_2.2.5 @@ -109,7 +108,6 @@ strstr@GLIBC_2.2.5 strtod@GLIBC_2.2.5 strtol@GLIBC_2.2.5 tolower@GLIBC_2.2.5 -trunc@GLIBC_2.2.5 _Unwind_Resume@GCC_3.0 _Z10c_ekkputl2PK12_EKKfactinfoPdS2_i _Z10clp_doublei @@ -135,11 +133,13 @@ _Z11fileAbsPathRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE _Z11log_wrapperd _Z11sin_wrapperd _Z12atan_wrapperd +_Z12ceil_wrapperd _Z12CoinFromFileIdEiRPT_iP8_IO_FILERi _Z12CoinFromFileIiEiRPT_iP8_IO_FILERi _Z12fabs_wrapperd _Z12remove_fixedP18CoinPresolveMatrixPK18CoinPresolveAction _Z12sqrt_wrapperd +_Z13floor_wrapperd _Z13testRedundantP18CoinPresolveMatrixPK18CoinPresolveAction _Z13transferCostsP18CoinPresolveMatrix _Z16check_tripletonsPK18CoinPresolveAction @@ -158,7 +158,6 @@ _Z22drop_zero_coefficientsP18CoinPresolveMatrixPK18CoinPresolveAction _Z22presolve_make_memlistsPiP13presolvehlinki _Z24WindowsErrorPopupBlockerv _Z26getFunctionValueFromStringPKcS0_d -_Z26presolve_delete_from_majoriiPKiPiS1_Pd _Z27presolve_delete_from_major2iiPiS_S_S_S_ _Z7clp_inti _Z8clp_freePv @@ -179,10 +178,10 @@ _Z9c_ekkrwctPK12_EKKfactinfoPdPiS3_PKiPK8EKKHlinkS8_PKsS2_ii _Z9c_ekkshffP12_EKKfactinfoP8EKKHlinkS2_i _Z9c_ekkshfvP12_EKKfactinfoP8EKKHlinkS2_i _Z9c_ekktriaP12_EKKfactinfoP8EKKHlinkS2_PiS3_S3_S3_i +_Z9check_rowPiPdS_S_ddii _Z9CoinCopyNIdEvPKT_iPS0_ _Z9CoinCopyNIiEvPKT_iPS0_ _Z9CoinFillNIiEvPT_iS0_ -_Z9CoinFillNItEvPT_iS0_ _Z9CoinIsnand _Z9CoinZeroNIdEvPT_i _Z9CoinZeroNIiEvPT_i @@ -223,6 +222,7 @@ _ZN12CoinMessagesC2Ei _ZN12CoinMessagesC2ERKS_ _ZN12CoinMessagesD1Ev _ZN12CoinMessagesD2Ev +_ZN12CoinRational16nearestRational_Eddl _ZN12CoinRelFltEqD0Ev _ZN12CoinRelFltEqD1Ev _ZN12CoinRelFltEqD2Ev @@ -358,6 +358,10 @@ _ZN14CoinSearchTreeI26CoinSearchTreeCompareDepthE8realpushEP16CoinTreeSiblings _ZN14CoinSearchTreeI26CoinSearchTreeCompareDepthED0Ev _ZN14CoinSearchTreeI26CoinSearchTreeCompareDepthED1Ev _ZN14CoinSearchTreeI26CoinSearchTreeCompareDepthED2Ev +_ZN14duprow3_action8presolveEP18CoinPresolveMatrixPK18CoinPresolveAction +_ZN14duprow3_actionD0Ev +_ZN14duprow3_actionD1Ev +_ZN14duprow3_actionD2Ev _ZN14FactorPointersC1EiiPiS0_ _ZN14FactorPointersC2EiiPiS0_ _ZN14FactorPointersD1Ev @@ -1142,6 +1146,8 @@ _ZN8CoinLpIO6readLpEP8_IO_FILEd _ZN8CoinLpIO6readLpEPKc _ZN8CoinLpIO6readLpEPKcd _ZN8CoinLpIO7freeAllEv +_ZN8CoinLpIO7loadSOSEiPK7CoinSet +_ZN8CoinLpIO7loadSOSEiPPK7CoinSet _ZN8CoinLpIO7writeLpEP8_IO_FILEb _ZN8CoinLpIO7writeLpEP8_IO_FILEdiib _ZN8CoinLpIO7writeLpEPKcb @@ -1340,6 +1346,8 @@ _ZNK14CoinFileIOBase11getFileNameEv _ZNK14CoinModelHash24hashEiiPK15CoinModelTriple _ZNK14CoinModelHash29hashValueEii _ZNK14CoinSearchTreeI26CoinSearchTreeCompareDepthE8compNameEv +_ZNK14duprow3_action4nameEv +_ZNK14duprow3_action9postsolveEP19CoinPostsolve
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
On Sun, Aug 27, 2017 at 03:16:46PM +0200, Anton Gladky wrote: > > Still I believe that this should be "correctly" fixed. > > You mean to increase so-version even if upstream does not do it and > to start the normal transition process? I think it is possible. That's actually your only option. Could someone check the symbols of the library before and after the upload and check whether some have been dropped? If there are, not bumping SONAME is a bug upstream should deal with by doing another release and doing so (and failing so, in Debian you should at the very least rename the binary package (doing somethng alike to the v5 thing done for libstdc++5)). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
> Still I believe that this should be "correctly" fixed. You mean to increase so-version even if upstream does not do it and to start the normal transition process? I think it is possible. > P.S.: Is it intended that coinutils contains > /usr/lib/x86_64-linux-gnu/pkgconfig/coindatasample.pc or is there a export > COIN_SKIP_PROJECTS="Sample" missing? I do not know, whether it is really needed. This line is in the .install-package [1] for a long time and I did not remove it last year, when overtook the maintenance on this package. [1] https://anonscm.debian.org/cgit/debian-science/packages/coinutils.git/tree/debian/coinor-libcoinutils-dev.install#n4 Cheers Anton
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
On Sun, Aug 27, 2017 at 01:59:04PM +0200, Rene Engelhard wrote: > for coinmp and libreoffice (5.4.1 release will be next week) if we uploaded > coinmp 1.8.3 to unstable... Now uploaded coinmp 1.8.3-2 to unstable. Let's see. Test succeeds at least. Still I believe that this should be "correctly" fixed. Regards, Rene P.S.: Is it intended that coinutils contains /usr/lib/x86_64-linux-gnu/pkgconfig/coindatasample.pc or is there a export COIN_SKIP_PROJECTS="Sample" missing? See https://anonscm.debian.org/cgit/debian-science/packages/coinmp.git/commit/?id=fccad9caf4d1698f1c294b73cd64f78c7d4a5727, without that I get that file in coinor-libcoinmp-dev
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
Hi, On Sun, Aug 27, 2017 at 01:26:30PM +0200, Anton Gladky wrote: > thanks for the bug report and sorry for inconvenience. Upstream did > not change the SO-version, so I decided not to do it explicitly and > request transition. Looks like the changes were minimal. > > If the coinmp-recompilation really fixes your problem, Did, yes, as said. Though I admit I am a bit confused given coinmp only links to cbc, not coinutils. (LO does use coinutils, too, though) > I would ask for binnmus of all rdepends. That would be better than nothing, though that would "hide" the problem and would cause problems if the libs for whatever reason get updated independently. (like right now.) I uploaded coinmp 1.8.3 to experimental today so I don't think we need bin-NMUs for coinmp and libreoffice (5.4.1 release will be next week) if we uploaded coinmp 1.8.3 to unstable... Regards, Rene
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
Hi Rene, thanks for the bug report and sorry for inconvenience. Upstream did not change the SO-version, so I decided not to do it explicitly and request transition. Looks like the changes were minimal. If the coinmp-recompilation really fixes your problem, I would ask for binnmus of all rdepends. Thanks Anton 2017-08-27 0:53 GMT+02:00 Rene Engelhard : > Package: coinor-libcoinutils3v5 > Version: 2.10.14+repack1-1 > Severity: serious
Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?
Package: coinor-libcoinutils3v5 Version: 2.10.14+repack1-1 Severity: serious Hi, LOs unit tests fail (don't get confused by the name, also tests the CoinMP based solver) since the last updates in sid: build CUT] sccomp_lpsolver S=/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2 && I=$S/instdir && W=$S/workdir &&mkdir -p $W/CppunitTest/ && rm -fr $W/CppunitTest/sccomp_lpsolver.test.user && mkdir $W/CppunitTest/sccomp_lpsolver.test.user &&rm -fr $W/CppunitTest/sccomp_lpsolver.test.core && mkdir $W/CppunitTest/sccomp_lpsolver.test.core && cd $W/CppunitTest/sccomp_lpsolver.test.core && ( LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs MALLOC_CHECK_=2 MALLOC_PERTURB_=153 $W/LinkTarget/Executable/cppunittester $W/LinkTarget/CppunitTest/libtest_sccomp_lpsolver.so --headless "-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share" "-env:UserInstallation=file://$W/CppunitTest/sccomp_lpsolver.test.user" "-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry xcsxcu:file://$W/unittest/registry" "-env:UNO_TYPES=file://$I/program/types.rdb file://$I/program/types/offapi.rdb" "-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb file://$W/Rdb/services.rdb" -env:URE_INTERNAL_LIB_DIR=file://$I/program -env:LO_LIB_DIR=file://$I/program -env:LO_JAVA_DIR=file://$I/program/classes --protector $W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector --protector $W/LinkTarget/Library/unobootstrapprotector.so unobootstrapprotector --protector $W/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector "-env:CPPUNITTESTTARGET=$W/CppunitTest/sccomp_lpsolver.test" ) > $W/CppunitTest/sccomp_lpsolver.test.log 2>&1 || ( RET=$?; $S/solenv/bin/gdb-core-bt.sh $W/LinkTarget/Executable/cppunittester $W/CppunitTest/sccomp_lpsolver.test.core $RET >> $W/CppunitTest/sccomp_lpsolver.test.log 2>&1; cat $W/CppunitTest/sccomp_lpsolver.test.log; $S/solenv/gbuild/platform/unittest-failed-default.sh Cppunit sccomp_lpsolver) Segmentation fault (core dumped) (anonymous namespace)::LpSolverTest::testLpSolver finished in: 579ms It looks like /data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/workdir/LinkTarget/Executable/cppunittester generated a core file at /data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/workdir/CppunitTest/sccomp_lpsolver.test.core/core Backtraces: [New LWP 11917] [New LWP 11918] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/workdir/Li'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f6dca552b9e in CoinMessageHandler::internalPrint() () from /usr/lib/x86_64-linux-gnu/libCoinUtils.so.3 [Current thread is 1 (Thread 0x7f6de7e2e740 (LWP 11917))] warning: File "/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/instdir/program/libuno_sal.so.3-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/instdir/program/libuno_sal.so.3-gdb.py line to your configuration file "/tmp/tmp.Aw8SthVoRj/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/tmp/tmp.Aw8SthVoRj/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: File "/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/instdir/program/libuno_cppu.so.3-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: File "/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/instdir/program/libmergedlo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". rax0x0 0 rbx0x55fce8a092d0 94544722957008 rcx0x55fce8a094f8 94544722957560 rdx0x30 48 rsi0x0 0 rdi0x55fce8a092d0 94544722957008 rbp0x55fce8a092d0 0x55fce8a092d0 rsp0x7ffe59817bc0 0x7ffe59817bc0 r8 0x4 4 r9 0x4 4 r100x0 0 r110x1 1 120x0 0 r130x1 1 r140x7ffe59818020 140730400079904 r150x0 0 rip0x7f6dca552b9e 0x7f6dca552b9e eflags 0x10212 [ AF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0