Crash on startup / openSUSE Tumbleweed


I’m attempting to run Logic-2.3.39-master.AppImage. This is what happens (launching from terminal):

> ./Logic-2.3.39-master.AppImage 
/tmp/.mount_Logic-xCYegK ~/app
ATTENTION: Sandboxing of this app has been disabled since the user namespace feature of your OS is disabled.
Please enable user namespaces or use the deb package.
  Executable path: /tmp/.mount_Logic-xCYegK/Logic
  Executable directory: /tmp/.mount_Logic-xCYegK
  Original working directory: /home/paradajz/app
  Current working directory: /tmp/.mount_Logic-xCYegK
(electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently "false".  It will change to be "true" in Electron 9.  For more information please check
Attempting to call a function in a renderer window that has been closed or released.
Function provided here: bundle.js:2139:6398
Remote event names: close

The app opens for roughly 2 seconds and then it crashes immediately.

On a similar note, trying to launch last v1 version results in this:

> ./Logic 
Root Path: /home/paradajz/app/Logic+1.2.18+(64-bit)/Logic 1.2.18 (64-bit)  [ /home/build/ob_logic/Source/Environment.cpp; Environment; 158 ]
Writeable Root Path: /home/paradajz/app/Logic+1.2.18+(64-bit)/Logic 1.2.18 (64-bit)  [ /home/build/ob_logic/Source/Environment.cpp; Environment; 185 ]
Temp Folder path: /tmp  [ /home/build/ob_logic/Source/Environment.cpp; Environment; 191 ]
Release Mode; analyzer path is /home/paradajz/app/Logic+1.2.18+(64-bit)/Logic 1.2.18 (64-bit)/Analyzers  [ /home/build/ob_logic/Source/Environment.cpp; Environment; 201 ]
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
  [ /home/build/ob_logic/Source/UsbDevice.cpp; UsbDevice; 62 ]
  [ /home/build/ob_logic/Source/UsbDevice.cpp; IsFirmwareDownloaded; 142 ]
4 endpoints  [ /home/build/ob_logic/Source/UsbDevice.cpp; IsFirmwareDownloaded; 146 ] QSslSocket: cannot resolve CRYPTO_num_locks QSslSocket: cannot resolve CRYPTO_set_id_callback QSslSocket: cannot resolve CRYPTO_set_locking_callback QSslSocket: cannot resolve ERR_free_strings QSslSocket: cannot resolve EVP_CIPHER_CTX_cleanup QSslSocket: cannot resolve EVP_CIPHER_CTX_init QSslSocket: cannot resolve sk_new_null QSslSocket: cannot resolve sk_push QSslSocket: cannot resolve sk_free QSslSocket: cannot resolve sk_num QSslSocket: cannot resolve sk_pop_free QSslSocket: cannot resolve sk_value QSslSocket: cannot resolve SSL_library_init QSslSocket: cannot resolve SSL_load_error_strings QSslSocket: cannot resolve SSL_get_ex_new_index QSslSocket: cannot resolve SSLv2_client_method QSslSocket: cannot resolve SSLv3_client_method QSslSocket: cannot resolve SSLv23_client_method QSslSocket: cannot resolve SSLv2_server_method QSslSocket: cannot resolve SSLv3_server_method QSslSocket: cannot resolve SSLv23_server_method QSslSocket: cannot resolve X509_STORE_CTX_get_chain QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf QSslSocket: cannot resolve SSLeay QSslSocket: cannot resolve SSLeay_version QSslSocket: cannot call unresolved function CRYPTO_num_locks QSslSocket: cannot call unresolved function CRYPTO_set_id_callback QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback QSslSocket: cannot call unresolved function SSL_library_init QSslSocket: cannot call unresolved function SSLv23_client_method QSslSocket: cannot call unresolved function sk_num
First device connected. Creating Primary Display.  [ /home/build/ob_logic/Source/LogicWindow_Devices.cpp; AttachedDevicesChangedSlot; 70 ]
GeneratePixmapEllipses: 0,864534 seconds  [ /home/build/ob_logic/Source/AnalogDisplayEngine.cpp; AnalogDisplayEngine; 38 ]
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
device change has triggered sprucing up the empty capture tab.  [ /home/build/ob_logic/Source/LogicWindow_Controller.cpp; ActiveDeviceChanged; 460 ]
setting PrimaryDisplay's Session to NULL.  [ /home/build/ob_logic/Source/PrimaryDisplay.cpp; SetSession; 562 ]
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Segmentation fault (core dumped)

@paradajz This is certainly strange behavior. Although our software doesn’t officially support openSUSE Tumbleweed, I have some follow questions for you below to potentially help us get to the bottom of this.

  1. How does Logic v1 behave? Does it eventually crash like Logic v2? If so, can you try the solution highlighted in the support article below?
    Linux Permission Requirements for Logic Software - Saleae Support

  2. As for running the Logic v2 software in openSUSE, I suspect that insufficient permissions may not be an issue since the app does launch briefly. I’m not quite sure if this will help, but the Ubuntu instructions for launching the app directly from the AppImage file is below. Does openSUSE have a similar file property setting that you can try?
    Installation - Saleae Support

  3. Did you notice the same behavior in older Logic v2 versions? I’m wondering if this is specifically caused by the latest version. Please give v2.3.37 a try below. Versions v2.3.38 and onwards added several major updates so I’m wondering if anything from these versions broke it for you.

Thanks for the response.

Regarding v2, yes, the executable flag is set (otherwise I wouldn’t be able to open it at all). This is the first v2 version I have ever tried. Same thing happens on .37.
Regarding v1 - that one doesn’t open at all - I just get the segfault in terminal and that’s all. However - it used to work just fine. I guess some update on my system broke it (I use rolling distro, after all).

EDIT: I realize I’m on unsupported distro so if this is something distro-specific I don’t mind - the software works fine on Windows, but I’d be happy to provide you with any info you might require.

1 Like


I’m not sure why both applications are crashing on launch. Do you have one of our devices attached to your system? If so, please remove it, and try again.

Also, you might want to try exacting the AppImage and running the software directly. I’m not on a Linux machine at the moment, but I think this should do it:

./Logic-2.3.39-master.AppImage --appimage-extract
cd squash-fs

Let me know if the console output is any different.

Second, this could be a problem with a dependency of our data processing back-end not found. This would not show up in ldd for either the AppImage or the extracted logic binary, because it’s loaded at runtime.

Instructions for checking for missing dependencies can be found here:

Specifically the part that asks you to run ldd & ldd -v.

Please send the output our way, and if you notice any missing dependencies, try installing them too.

Just on the off chance it’s the same issue - on Fedora it crashes on startup due to a libcrypto mismatch.

The following works for me;
LD_PRELOAD=/usr/lib64/ ./Logic-2.3.39-master.AppImage

I have the same issue on Ubuntu 20.04.
Trying with Logic-2.3.27 and Logic-2.3.39 reports the same error.
Trying with the latest version (Logic-2.3.42), it behaves the same way (open for 2 seconds, then crash), but the error message is even less useful:

> ./Logic-2.3.42-master.AppImage 
/tmp/.mount_Logic-bLPN5A ~
  Executable path: /tmp/.mount_Logic-bLPN5A/Logic
  Executable directory: /tmp/.mount_Logic-bLPN5A
  Original working directory: /home/fabien
  Current working directory: /tmp/.mount_Logic-bLPN5A

Unexpected crash report id length
Failed to get crash dump id.
Report Id: 

I also tried with the --no-sandbox argument, same thing happens.

I did what @markgarrison wrote, it behave the same, and no dependencies are missing.

The most curious thing is that it used to work.
A few month ago the same thing happens but I did not dig in this issue at that moment.
Can network configuration affect it ? That’s the only difference I noticed between the “working” and “failing” cases.

Sorry for the trouble with this!

open for 2 seconds, then crash

The application window actually appears? This suggests it’s crashing in the renderer process, not the main process, which likely indicates it dies when trying to load our shared library. (Electron apps use a handful of processes)

From the extracted app-image, let’s check the supplied for missing dependencies.

Could you run ldd squashfs-root/resources/linux/ and send us the output?

Yes, the window appear, and I can see the Saleae logo with “connecting…” during less than a second.

Here is the return of ldd:

> ldd (0x00007fffdbfce000) => /lib/x86_64-linux-gnu/ (0x00007f7336018000) => /lib/x86_64-linux-gnu/ (0x00007f7335fdd000) => /lib/x86_64-linux-gnu/ (0x00007f7335fd2000) => /lib/x86_64-linux-gnu/ (0x00007f7335fb5000) => /lib/x86_64-linux-gnu/ (0x00007f7335fb0000) => /home/fabien/squashfs-root/resources/linux/./ (0x00007f7335ecd000) => /lib/x86_64-linux-gnu/ (0x00007f7335ea8000) => /lib/x86_64-linux-gnu/ (0x00007f7335ea2000) => /lib/x86_64-linux-gnu/ (0x00007f7335d53000) => /lib/x86_64-linux-gnu/ (0x00007f7335d38000) => /lib/x86_64-linux-gnu/ (0x00007f7335b46000)
    /lib64/ (0x00007f7338976000)

If needed, I can launch a debug build with gdb and send the result.

@fabien.bonneval Thanks for sending that over. You’re right — nothing seems to be missing. I’ll review the output with our team here to see if we have any other suggestions.

@fabien.bonneval could you try launching with gdb and see if it catches this at all? It might be tricky since the process that is crashing is a child process of the one you’re launching. If it’s able to pause on the crash signal, the gcore aught to dump the core. Please send it to support and not post it here, as it’s possible it could contain personal information.
We have copies of the unstripped binaries here we can use for symbolification.
Let’s also grab any logs the app might have produced. It’s possible it’s not producing any, given that I suspect the crash is occurring in the shared library that contains the logging system, before logging can start.
Those would likely be in ~/.config/Logic/Logic/logs or similar. Check the directory before and after the crash to see if any new files are created.

Additionally, before launching the app, try setting this environment variable:
And then send us the console output of the application once it’s crashed. Hopefully that will redirect the renderer process log to the terminal, which might give us more clews.

I still suspect this might be some sort of dependency issue, given that the app seems to be crashing while loading our shared library, but right now I don’t see any issues.

Unfortunately, it “broke back” to working state.
I did nothing special since the last time it failed, no new packet installation.
And of course, in order to see new logs, I removed all the old ones.
So stand by for now, I will post again here if it happens again.

Thank you for your help, I keep you informed.