Logic 2 crashing at startup on Fedora 32

1

Thought I’d try upgrading from my ancient 1.1 (!) installation, but all the recent clients segfault at startup on my Fedora machine.

The last working AppImage download is 2.2.14, after that they crash in libcrypto… Happy to provide any further logs if required… Thanks!

2

Sorry for the trouble!

Please post the console logs from tying to run the appimage.

Then, try extracting the appimage and running the logic binary directly:

./Logic-2.3.10-master.AppImage --appimage-extract
cd squashfs-root
./Logic

And post the output of Logic there.

Since 2.2.14, I think we’ve upgraded the version of Electron we use, and we introduced a Python interpreter to run high level analyzer and measurement extensions. We’ve seen a number of issues with Python on some Linux distros, but I think we were able to resolve them.

My first guess is that a libcrypto issue may have been introduced through electron, but our C++ code also uses it, so it’s not clear where the problem is coming from. I thought we finally managed to get it statically linked, but I might be wrong.

3

Thanks Mark,

No worries - really appreciate the cross platform client, and the work that must go into it!

I’ve noticed that from the first version that crashes (2.2.15), there is a dependency on libnsl (by default Fedora only ships with libnsl2 now, so had to install). Without this installed, it errors out before the crash.

Not much console output before the crash (2.3.10);

$ ./Logic
Environment
Executable path: /home/jone/Downloads/squashfs-root/Logic
Executable directory: /home/jone/Downloads/squashfs-root
Original working directory: /home/jone/Downloads/squashfs-root
Current working directory: /home/jone/Downloads/squashfs-root
Python Home: /home/jone/Downloads/squashfs-root/resources/linux/pythonlibs
Failed to get crash dump id.
Report Id: {“response”:“ok”,“_rxid”:"26000000-3
Segmentation fault (core dumped)

Have got a backtrace from gdb when it crashes (2.3.10);

(gdb) bt
#0 0x00007ffff7dce905 in OPENSSL_ia32_cpuid () from /lib64/libcrypto.so.1.0.2o
#1 0x00007fffd8fa4385 in ?? () from /home/jone/Downloads/squashfs-root/resources/linux/libgraph_server_shared.so
#2 0x00007fffd8c0f3aa in _init () from /home/jone/Downloads/squashfs-root/resources/linux/libgraph_server_shared.so
#3 0x00007fffd88e18d8 in ?? () from /home/jone/Downloads/squashfs-root/resources/linux/libAnalyzer.so
#4 0x00007ffff7fe1778 in call_init.part () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff7fe18c1 in _dl_init () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ffff60a11b5 in _dl_catch_exception () from /lib64/libc.so.6
#7 0x00007ffff7fe5c64 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#8 0x00007ffff60a1158 in _dl_catch_exception () from /lib64/libc.so.6
#9 0x00007ffff7fe517e in dl_open () from /lib64/ld-linux-x86-64.so.2
#10 0x00007ffff774a39c in dlopen_doit () from /lib64/libdl.so.2
#11 0x00007ffff60a1158 in dl_catch_exception () from /lib64/libc.so.6
#12 0x00007ffff60a1223 in dl_catch_error () from /lib64/libc.so.6
#13 0x00007ffff774abd9 in dlerror_run () from /lib64/libdl.so.2
#14 0x00007ffff774a428 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#15 0x00007ffff5f43af0 in ffi_call_unix64 () from /lib64/libffi.so.6
#16 0x00007ffff5f432ab in ffi_call () from /lib64/libffi.so.6
#17 0x00007fffe06d7a9d in FFI::FFI::FFICall(Napi::CallbackInfo const&) () from /tmp/.org.chromium.Chromium.M3nf3s
#18 0x00007fffe06dd897 in Napi::details::CallbackData<void (*)(Napi::CallbackInfo const&), void>::Wrapper(napi_env*, napi_callback_info*) () from /tmp/.org.chromium.Chromium.M3nf3s
#19 0x000055555be78bc1 in ?? ()
#20 0x000055555c3b07a8 in ?? ()

Regards,
Jon

4

Thanks Jon, libgraph_server_shared is definitely our code, not the electron framework. That stack trace shows the call from electron into our library, most likely constructing our back end data processing system, graph_sever.

The crash in OPENSSL_ia32_cpuid is odd though.

Can you send me your computer’s processor model name/number?
I once saw a tangentially related problem with OpenSSL on specific Intel CPUs on Windows, that was specific to a N4200 series of processors, and a few other related series. The problem that openSSL was making bad assumptions about the instruction set capabilities of those processors, which was fixed in newer versions of openSSL.

Also, you might want to try the solution mentioned here:

That would probably look like:
env OPENSSL_ia32cap="~0x10000000" ./Logic

5

Thanks Mark, sorted…

I couldn’t fix it with the capabilities, but your reply got me looking in the right direction. I saw some other reports of steam crashes, due to dynamically linking an incorrect openssl version.

Looking at my stack trace above, can see it was loading /lib64/libcrypto.so.1.0.2o which comes from an openssl 1.0 compatibility package. Preloading the 1.1 library did the trick, and now the later Logic versions all start fine with the following syntax;

LD_PRELOAD=/usr/lib64/libcrypto.so.1.1 ./Logic-2.3.10-master.AppImage

Will confess I don’t understand why it was trying to link to the earlier version, but happy to be up and running.

Thanks again,
Jon

6

Thanks Jon, I hadn’t realized that we’ve broken compatibility with OpenSSL 1.0.x. This issue seems to crop up every so often, we really just need to statically link this on Linux.