segfault in ctest

[jajhall]

From a user...

I just followed the instructions here and the final step ctest segfaults, although LastTest.log looks OK

cd HiGHS
cmake -S. -B build 
cmake --build build --parallel
cd build
ctest

My machines are both Ubuntu 24.04, one with i5-2300 and the other i7-4770K

I (@jajhall) have tried to reproduce this (on a machine also running Ubuntu 24.04), and don't get a segfault. However, when building with -DCMAKE_BUILD_TYPE=debug, I get

valgrind ctest
==1738678== Memcheck, a memory error detector
==1738678== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1738678== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==1738678== Command: ctest
==1738678== 
==1738678== Warning: set address range perms: large range [0x9e2b000, 0x29e2b000) (noaccess)
==1738678== Warning: set address range perms: large range [0x29e2b000, 0x49e2b000) (noaccess)
==1738678== Warning: ignored attempt to set SIGRT32 handler in sigaction();
==1738678==          the SIGRT32 signal is used internally by Valgrind
==1738678== Warning: ignored attempt to set SIGRT32 handler in sigaction();
==1738678==          the SIGRT32 signal is used internally by Valgrind
==1738678== Warning: client switching stacks?  SP change: 0x1ffefff940 --> 0xc0000a47d8
==1738678==          to suppress, use: --max-stackframe=687212220056 or greater
==1738678== Warning: client switching stacks?  SP change: 0xc0000a4740 --> 0x1ffefff9d8
==1738678==          to suppress, use: --max-stackframe=687212219752 or greater
==1738678== Warning: client switching stacks?  SP change: 0x1ffefff9d8 --> 0xc0000a4740
==1738678==          to suppress, use: --max-stackframe=687212219752 or greater
==1738678==          further instances of this message will not be shown.
==1738678== Conditional jump or move depends on uninitialised value(s)
==1738678==    at 0x560577: ??? (in /usr/bin/snap)
==1738678==    by 0x560D09: ??? (in /usr/bin/snap)
==1738678==    by 0x5612EC: ??? (in /usr/bin/snap)
==1738678==    by 0x579A96: ??? (in /usr/bin/snap)
==1738678==    by 0x57E2C4: ??? (in /usr/bin/snap)
==1738678==    by 0x1FFEFFF9F7: ???
==1738678==    by 0x57E2C4: ??? (in /usr/bin/snap)
==1738678==    by 0x165D59F: ???
==1738678== 

and a whole load of other messasges relating to /usr/bin/snap, and maybe that's causing the segfault.

[jajhall]

Thanks for your reply. I think I've found the culprit.

The offending program is call_highs_from_cpp. Back in May 2024, I compiled and installed HiGHS (version 1.7.0), and the built libhighs.so.1 = libhighs.so.1.7.0 resides in /usr/local/lib after installing.

Yesterday, I compiled HiGHS (version 1.9.0) and ran ctetst. At this point, build/bin/call_highs_from_cpp has been compiled from version 1.9.0, but it depends on /usr/local/lib/libhighs.so.1, which still points to the 1.7.0 version. I hadn't sudo cmake --install build yet because I wanted to test first.

hs556@bki5:~/Downloads/HiGHS/build/bin$ ldd call_highs_from_cpp
linux-vdso.so.1 (0x00007ffca13e2000)
libhighs.so.1 => /usr/local/lib/libhighs.so.1 (0x0000771c3b800000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x0000771c3b400000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000771c3be99000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000771c3b000000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x0000771c3be7b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000771c3b717000)
/lib64/ld-linux-x86-64.so.2 (0x0000771c3befd000)

Indeed, manually changing out /usr/local/lib/libhighs.so.1 to point to the 1.9.0 version will make the segfault go away.