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
~/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.
Environment
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 https://github.com/electron/electron/issues/18397
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:
@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.
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
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. Saleae
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.
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
./Logic
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.
Hi,
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 ~
~
Environment
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.
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 libgraph_server_shared.so for missing dependencies.
Could you run ldd squashfs-root/resources/linux/libgraph_server_shared.so and send us the output?
@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: export ELECTRON_ENABLE_LOGGING=true
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.