Crashing in Raspberry Pi Arm64 Linux Environment

liam.ogletree · May 6, 2026, 4:45pm

Hi,

I’m attempting to run Logic2 in a headless linux environment, and the application is crashing. I’ve looked through previous posts but have been unable to resolve the issue.

Some details:

OS information (https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2026-04-21/2026-04-21-raspios-trixie-arm64-lite.img.xz):

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.4
ID=debian

I’m getting the latest aarch64 release using the following:

wget -O Logic2 "http://logic2api.saleae.com/download?os=linux&arch=arm64&release_channel=insider"
chmod +x Logic2

I’m manually installing dev rules using the following (and then reloading):

wget -O 99-SaleaeLogic.rules https://www.saleae.com/support-assets/99-SaleaeLogic.rules
sudo cp 99-SaleaeLogic.rules /etc/udev/rules.d

I’m installing XVFB and its prerequisites:

sudo apt install xvfb libatk1.0-0 libatk-bridge2.0-0 libgtk-3-0 libgbm1

I’m installing the automation API module:

pip install logic2-automation

I see the Logic Pro 16 on the bus:

Bus 002 Device 002: ID 21a9:1006 Saleae, Inc. Logic Pro 16

When I then run the following command to start the application…

xvfb-run /usr/local/bin/Logic2 --no-sandbox --enable-logging --disable-gpu --automation

…I see the following log messages:

Environment
  Executable path: /tmp/.mount_Logic2mhcPHk/usr/lib/logic/Logic.bin
  Executable directory: /tmp/.mount_Logic2mhcPHk/usr/lib/logic
  Original working directory: /tmp/.mount_Logic2mhcPHk/usr
  Current working directory: /tmp/.mount_Logic2mhcPHk/usr/lib/logic
  Process ID: 5665
Crash reporting enabled. Machine ID: 9617f59b-9f40-4e99-97e0-98d53b54b274. Upload to server: false
[5665:0506/113916.627364:WARNING:electron_api_native_image.cc(194)] Failed to load image from path '/tmp/.mount_Logic2mhcPHk/usr/lib/logic/resources/linux-arm64/LogicIcon.png'
[5703:0506/113917.169835:WARNING:gpu_memory_buffer_support_x11.cc(49)] dri3 extension not supported.
[5665:0506/113917.179787:WARNING:bluez_dbus_manager.cc(247)] Floss manager not present, cannot set Floss enable/disable.
[5703:0506/113917.179442:WARNING:sandbox_linux.cc(393)] InitializeSandbox() called with multiple threads in process gpu-process.
[5665:0506/113920.921598:INFO:CONSOLE(45)] "the shortcut %s has multiple commands (%O) registered that do not allow shortcut overlap CmdOrCtrl+a markers:all-selected,advancedMeasurements:select-all-ranges", source: file:///tmp/.mount_Logic2mhcPHk/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (45)
[5665:0506/113925.795061:INFO:CONSOLE(1159)] "console.group", source: file:///tmp/.mount_Logic2mhcPHk/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (1159)
[5665:0506/113925.795905:INFO:CONSOLE(2428)] "response came back, but no matching callback or pipe subscriber was found. Id: 0", source: file:///tmp/.mount_Logic2mhcPHk/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (2428)
[5665:0506/113925.796204:INFO:CONSOLE(2428)] "type: response", source: file:///tmp/.mount_Logic2mhcPHk/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (2428)
[5665:0506/113925.796771:INFO:CONSOLE(2428)] "[object Object]", source: file:///tmp/.mount_Logic2mhcPHk/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (2428)
[5665:0506/113925.796996:INFO:CONSOLE(1159)] "console.groupEnd", source: file:///tmp/.mount_Logic2mhcPHk/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (1159)
Renderer process crashed - see https://www.electronjs.org/docs/tutorial/application-debugging for potential debugging information.
@saleae/electron/main: renderer process died { reason: 'crashed', exitCode: 6 }
sendToFrame() failed: Error: Render frame was disposed before WebFrameMain could be accessed
Attempting to call a function in a renderer window that has been closed or released.
Function provided here: bundle.js:1368:125845
Remote event names: close

To help debug, if I run /usr/local/bin/Logic2 --appimage-extract and ldd -v libgraph_server_shared.so, I see the following:

linux-vdso.so.1 (0x0000007fb29ec000)
	libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007faf5d0000)
	libAnalyzer.so => /home/logletre/squashfs-root/usr/lib/logic/resources/linux-arm64/./libAnalyzer.so (0x0000007faf420000)
	libtirpc.so.3 => /lib/aarch64-linux-gnu/libtirpc.so.3 (0x0000007faf3c0000)
	libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000007faf360000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007faf2b0000)
	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007faf270000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007faf0b0000)
	/lib/ld-linux-aarch64.so.1 (0x0000007fb29b0000)
	libgssapi_krb5.so.2 => /lib/aarch64-linux-gnu/libgssapi_krb5.so.2 (0x0000007faf040000)
	libcap.so.2 => /lib/aarch64-linux-gnu/libcap.so.2 (0x0000007faf010000)
	libkrb5.so.3 => /lib/aarch64-linux-gnu/libkrb5.so.3 (0x0000007faef20000)
	libk5crypto.so.3 => /lib/aarch64-linux-gnu/libk5crypto.so.3 (0x0000007faeed0000)
	libcom_err.so.2 => /lib/aarch64-linux-gnu/libcom_err.so.2 (0x0000007faeea0000)
	libkrb5support.so.0 => /lib/aarch64-linux-gnu/libkrb5support.so.0 (0x0000007faee70000)
	libkeyutils.so.1 => /lib/aarch64-linux-gnu/libkeyutils.so.1 (0x0000007faee40000)
	libresolv.so.2 => /lib/aarch64-linux-gnu/libresolv.so.2 (0x0000007faee10000)

	Version information:
	./libgraph_server_shared.so:
		libstdc++.so.6 (GLIBCXX_3.4) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4.15) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4.22) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.1) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.3) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.5) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.7) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.8) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.9) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.11) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libudev.so.1 (LIBUDEV_183) => /lib/aarch64-linux-gnu/libudev.so.1
		libm.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libm.so.6
		libm.so.6 (GLIBC_2.27) => /lib/aarch64-linux-gnu/libm.so.6
		libm.so.6 (GLIBC_2.29) => /lib/aarch64-linux-gnu/libm.so.6
		libm.so.6 (GLIBC_2.35) => /lib/aarch64-linux-gnu/libm.so.6
		libgcc_s.so.1 (GCC_3.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_3.3) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_4.2.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_4.5.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.25) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.30) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.32) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.33) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.35) => /lib/aarch64-linux-gnu/libc.so.6
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
	/lib/aarch64-linux-gnu/libstdc++.so.6:
		libm.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libm.so.6
		libc.so.6 (GLIBC_2.38) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.25) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.18) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.32) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.33) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.36) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
		libgcc_s.so.1 (GCC_4.2.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_3.3) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_3.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_4.5.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
	/home/logletre/squashfs-root/usr/lib/logic/resources/linux-arm64/./libAnalyzer.so:
		libstdc++.so.6 (GLIBCXX_3.4) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4.15) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4.21) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4.22) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.1) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.3) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.7) => /lib/aarch64-linux-gnu/libstdc++.so.6
		libm.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libm.so.6
		libgcc_s.so.1 (GCC_3.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_3.3) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_4.2.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_4.5.0) => /lib/aarch64-linux-gnu/libgcc_s.so.1
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.33) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.35) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libtirpc.so.3:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libgssapi_krb5.so.2 (gssapi_krb5_2_MIT) => /lib/aarch64-linux-gnu/libgssapi_krb5.so.2
		libc.so.6 (GLIBC_2.32) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.38) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libudev.so.1:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.25) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.28) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.36) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.32) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.33) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.26) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.30) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.38) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libm.so.6:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libc.so.6 (GLIBC_ABI_DT_RELR) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_PRIVATE) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libgcc_s.so.1:
		libc.so.6 (GLIBC_2.35) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libc.so.6:
		ld-linux-aarch64.so.1 (GLIBC_2.35) => /lib/ld-linux-aarch64.so.1
		ld-linux-aarch64.so.1 (GLIBC_PRIVATE) => /lib/ld-linux-aarch64.so.1
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
	/lib/aarch64-linux-gnu/libgssapi_krb5.so.2:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libk5crypto.so.3 (k5crypto_3_MIT) => /lib/aarch64-linux-gnu/libk5crypto.so.3
		libkrb5support.so.0 (krb5support_0_MIT) => /lib/aarch64-linux-gnu/libkrb5support.so.0
		libkrb5.so.3 (krb5_3_MIT) => /lib/aarch64-linux-gnu/libkrb5.so.3
		libc.so.6 (GLIBC_2.27) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.25) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.38) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.33) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libcap.so.2:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libc.so.6 (GLIBC_2.33) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.38) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libkrb5.so.3:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libresolv.so.2 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libresolv.so.2
		libk5crypto.so.3 (k5crypto_3_MIT) => /lib/aarch64-linux-gnu/libk5crypto.so.3
		libkrb5support.so.0 (krb5support_0_MIT) => /lib/aarch64-linux-gnu/libkrb5support.so.0
		libkeyutils.so.1 (KEYUTILS_1.0) => /lib/aarch64-linux-gnu/libkeyutils.so.1
		libkeyutils.so.1 (KEYUTILS_1.5) => /lib/aarch64-linux-gnu/libkeyutils.so.1
		libkeyutils.so.1 (KEYUTILS_0.3) => /lib/aarch64-linux-gnu/libkeyutils.so.1
		libc.so.6 (GLIBC_2.25) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.33) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.38) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libk5crypto.so.3:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libkrb5support.so.0 (krb5support_0_MIT) => /lib/aarch64-linux-gnu/libkrb5support.so.0
		libc.so.6 (GLIBC_2.33) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.25) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.38) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libcom_err.so.2:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.38) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libkrb5support.so.0:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libc.so.6 (GLIBC_2.25) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.38) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libkeyutils.so.1:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6
	/lib/aarch64-linux-gnu/libresolv.so.2:
		ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
		libc.so.6 (GLIBC_ABI_DT_RELR) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.34) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_PRIVATE) => /lib/aarch64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/aarch64-linux-gnu/libc.so.6

So, I’m not seeing that I’m missing any libraries (which was the problem here: Issue with Logic startup - #5 by alex ).

Any help would be appreciated! Alternatively, if something about my setup isn’t supported, that would also be great to know.

Thanks!

liam.ogletree · May 6, 2026, 4:53pm

Since the aarch64 linux support on Raspberry Pi OS is new (per Official Arm64 support for Windows and Linux ), I wanted to step through and make sure I provide all the relevant information:

details provided above
Raspberry Pi 4 Model B
Logic Pro 16
distro linked above
uname -a output:

Linux logletre-pi 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux

N/A
see above
unknown
no

Thanks!

liam.ogletree · May 6, 2026, 8:33pm

For testing purposes, I tried to get Logic2 running on a desktop Raspberry Pi OS aarch64 setup but am experiencing the same issue – updating the title of this issue to reflect that this is occurring in both desktop/headless environments. However, having the desktop environment has clarified that the application crashes only when the Saleae Logic Pro 16 is connected. If I go back to the headless setup, I am verifying that the application crashes only when I plug in the Logic device.

I am using a powered USB 3.0 hub to connect the Saleae to the Raspberry Pi, so it shouldn’t be a power-related issue (I’m not seeing voltage warnings or brownouts on the Pi). When I connect the Saleae, Logic2 recognizes that I’ve plugged the Logic device in, it reports ‘connecting’, then shows ‘connected’ and the image of the Logic device is green before it crashes.

Thanks!

timreyes · May 8, 2026, 12:42am

@liam.ogletree Sorry for the trouble with that! We’ve tested headless operation on Ubuntu 20.04 using XVFB (details below).

Unfortunately, we haven’t tested this on our new Arm64 software as it’s quite new.

Thanks for sending all of your debugging details by the way! I’ll review this all with the rest of the team here.

liam.ogletree · May 8, 2026, 2:48pm

Hi Tim,

Thanks for the quick reply! I have been using XVFB as described in the linked guide.

Please let me know if I can provide any additional debug information to help.

Thanks!

markgarrison · May 14, 2026, 11:03pm

Hi @liam.ogletree,

Sorry for the trouble with this. The fact that it’s only crashing when initalizing the device is strong clue. That could mean a few things. It could be an actual issue with the device initialization, or, it could be a problem with the webGL context that we initialize when we create the first session for Logic Pro 16. (You can use the automation API to perform a simulated capture w/ analog channels. If that does not crash, then that should rule out issues with webGL)

Based on the output so far, it looks like it’s hard crashing, but I wasn’t able to find any crash reports based on your machine ID. This makes sense, even if you are online, you have to opt-in to crash report uploading, which isn’t easy on a headless environment.

Getting crash reporting uploading enabled would be the quickest way for us to debug. (It’s a lot more painful for me to symbolicate a crash dumps w/ electron symbols manually than it is to use our crash report manager)

If you set the environment variable SALEAE_OVERRIDE_ENABLE_CRASH_REPORTING=1, and try this again, you should see Crash reporting enabled....Upload to server: true instead of Crash reporting enabled....Upload to server: false, and crash reports should automatically upload if you’re online.

Otherwise you can check ~/.config/Logic/Crashpad/ (and subdirectories) for *.dmp files and send one to us. (Contact Us | Saleae)

I would also recommend setting ELECTRON_ENABLE_LOGGING=1, which will produce a lot more console output to send us, and to aslo check ~/.config/Logic/Logs after a crash for a new log file, and send us both the console output and the log file.

Hopefully we can find a quick fix for this!

dominic.styblo · May 15, 2026, 7:26am

Hi @markgarrison ,
Today I set up a similar configuration: Raspberry Pi 4, Pi OS, Desktop Version.
I’m having a problem that behaves in exactly the same way. I can start the Logic software and interact with the UI just fine. When I connect my Logic 16 Pro, I can see it pop up in the bottom left corner. It’s clearly initialising. After that, when it tries to open the session in the UI, the program just crashes. I also tried creating a demo session, which had the same result. Maybe that helps you to narrow the problem further down.

liam.ogletree · May 15, 2026, 3:44pm

@dominic.styblo I’m glad to hear that I’m not the only one running into this issue.

@markgarrison I tried using the demo Logic device and it hard crashed – same error as before. I’ll note that it crashes regardless of the demo device I select, e.g., it fails for both Logic 8 and Logic 16 Pro.

My machine ID is:

Machine ID: 27e6406c-70ff-4a9d-9bcf-8ed876b52cc7

You should be able to find multiple crash reports for this machine ID between 10 AM CDT and 11 AM CDT on 5/15/2026.

After exporting the environment variables, my log doesn’t look very different, but here is the console output and log file:

logletre@logletre-pi:~ $ xvfb-run /usr/local/bin/Logic2.AppImage --no-sandbox --disable-gpu --enable-logging
Environment
  Executable path: /tmp/.mount_Logic2kjKPgH/usr/lib/logic/Logic.bin
  Executable directory: /tmp/.mount_Logic2kjKPgH/usr/lib/logic
  Original working directory: /tmp/.mount_Logic2kjKPgH/usr
  Current working directory: /tmp/.mount_Logic2kjKPgH/usr/lib/logic
  Process ID: 2910
Crash reporting enabled. Machine ID: 27e6406c-70ff-4a9d-9bcf-8ed876b52cc7. Upload to server: true
[2910:0515/104304.256397:WARNING:electron_api_native_image.cc(194)] Failed to load image from path '/tmp/.mount_Logic2kjKPgH/usr/lib/logic/resources/linux-arm64/LogicIcon.png'
[2910:0515/104304.762596:WARNING:bluez_dbus_manager.cc(247)] Floss manager not present, cannot set Floss enable/disable.
[2954:0515/104305.143855:WARNING:gpu_memory_buffer_support_x11.cc(49)] dri3 extension not supported.
[2954:0515/104305.159563:WARNING:sandbox_linux.cc(393)] InitializeSandbox() called with multiple threads in process gpu-process.
[2910:0515/104308.837131:INFO:CONSOLE(45)] "the shortcut %s has multiple commands (%O) registered that do not allow shortcut overlap CmdOrCtrl+a markers:all-selected,advancedMeasurements:select-all-ranges", source: file:///tmp/.mount_Logic2kjKPgH/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (45)
[2910:0515/104313.964205:INFO:CONSOLE(1159)] "console.group", source: file:///tmp/.mount_Logic2kjKPgH/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (1159)
[2910:0515/104313.965715:INFO:CONSOLE(2428)] "response came back, but no matching callback or pipe subscriber was found. Id: 0", source: file:///tmp/.mount_Logic2kjKPgH/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (2428)
[2910:0515/104313.966362:INFO:CONSOLE(2428)] "type: response", source: file:///tmp/.mount_Logic2kjKPgH/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (2428)
[2910:0515/104313.966903:INFO:CONSOLE(2428)] "[object Object]", source: file:///tmp/.mount_Logic2kjKPgH/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (2428)
[2910:0515/104313.967253:INFO:CONSOLE(1159)] "console.groupEnd", source: file:///tmp/.mount_Logic2kjKPgH/usr/lib/logic/resources/app.asar/dist/logic/bundle.js (1159)
Renderer process crashed - see https://www.electronjs.org/docs/tutorial/application-debugging for potential debugging information.
@saleae/electron/main: renderer process died { reason: 'crashed', exitCode: 6 }
sendToFrame() failed: Error: Render frame was disposed before WebFrameMain could be accessed
Attempting to call a function in a renderer window that has been closed or released.
Function provided here: bundle.js:1368:125845
Remote event names: close

[2026-05-15 10:33:34.053] [main] [info] [saleae_log.cpp:356] Logfile path set to: /home/logletre/.config/Logic/logs/2026-05-15_10-33-27_2da92aa5-cf10-40dc-b5ff-7cbf853255da/graphio.log
[2026-05-15 10:33:34.053] [main] [critical] [saleae_log.cpp:359] Global logging level is set to: info
[2026-05-15 10:33:36.411] [main] [info] [graph_server.cpp:821] DeleteGraphData SeesionId: -2
[2026-05-15 10:33:36.411] [main] [info] [graph_server.cpp:843] DeleteGraph( -2 ) called
[2026-05-15 10:33:37.432] [usb] [info] [DevicesManager.cpp:169] Resetting DevicesManager
[2026-05-15 10:33:37.522] [device] [info] [GenericDevice.cpp:60] Updating device state (Logic8/0xF4243) from DSInitializing(msg=, progress=0%) to DSReady()
[2026-05-15 10:33:37.523] [device] [info] [GenericDevice.cpp:60] Updating device state (LogicPro8/0xF4244) from DSInitializing(msg=, progress=0%) to DSReady()
[2026-05-15 10:33:37.523] [device] [info] [GenericDevice.cpp:60] Updating device state (LogicPro16/0xF4241) from DSInitializing(msg=, progress=0%) to DSReady()
[2026-05-15 10:33:41.456] [usb] [info] [base_usb_manager.cpp:28] SALEAE_IGNORE_DEVICE is set to NullOpt
[2026-05-15 10:33:41.457] [usb] [info] [LinuxUsbDevice.cpp:185] USB Speed: USB_FULL_SPEED
[2026-05-15 10:33:41.457] [usb] [info] [usb_device_utils.cpp:214] IsFirmwareDownloaded
[2026-05-15 10:33:41.457] [usb] [info] [usb_device_utils.cpp:219] 0 endpoints
[2026-05-15 10:33:41.457] [usb] [info] [DevicesManager.cpp:41] Downloading firmware
[2026-05-15 10:33:41.483] [usb] [info] [usb_device_utils.cpp:199] Firmware download took 0.022376 seconds.
[2026-05-15 10:33:42.583] [usb] [info] [DevicesManager.cpp:570] USB device removed (LogicPro16)
[2026-05-15 10:33:42.584] [usb] [info] [LinuxUsbDevice.cpp:185] USB Speed: USB_SUPER_SPEED
[2026-05-15 10:33:42.584] [usb] [info] [usb_device_utils.cpp:214] IsFirmwareDownloaded
[2026-05-15 10:33:42.584] [usb] [info] [usb_device_utils.cpp:219] 3 endpoints
[2026-05-15 10:33:42.589] [device] [info] [LogicProfessionalDevice.cpp:58] SUPER SPEED
[2026-05-15 10:33:42.589] [device] [info] [LogicProfessionalDevice.cpp:68] Firmware build date: Logic Pro Firmware Compiled Oct 25 2022  16:42:01
[2026-05-15 10:33:42.592] [device] [info] [LogicProfessionalDevice.cpp:84] Logic Pro 16 Device ID: 0x46cfe74a24f69820
[2026-05-15 10:33:42.595] [device] [info] [LogicProfessionalDevice.cpp:93] Hardware revision: 1.2.0
[2026-05-15 10:33:42.715] [device] [info] [GenericDevice.cpp:60] Updating device state (LogicPro16/0x46CFE74A24F69820) from DSInitializing(msg=, progress=0%) to DSInitializing(msg=, progress=5.053899645839255%)
[2026-05-15 10:33:42.842] [device] [info] [GenericDevice.cpp:60] Updating device state (LogicPro16/0x46CFE74A24F69820) from DSInitializing(msg=, progress=5.053899645839255%) to DSInitializing(msg=, progress=10.10779929167851%)
[2026-05-15 10:33:42.963] [device] [info] [GenericDevice.cpp:60] Updating device state (LogicPro16/0x46CFE74A24F69820) from DSInitializing(msg=, progress=10.10779929167851%) to DSInitializing(msg=, progress=15.161698937517777%)
[2026-05-15 10:33:43.085] [device] [info] [GenericDevice.cpp:60] Updating device state (LogicPro16/0x46CFE74A24F69820) from DSInitializing(msg=, progress=15.161698937517777%) to DSInitializing(msg=, progress=20.215598583357032%)
[2026-05-15 10:33:43.206] [device] [info] [GenericDevice.cpp:60] Updating device state (LogicPro16/0x46CFE74A24F69820) from DSInitializing(msg=, progress=20.215598583357032%) to DSInitializing(msg=, progress=25.269498229196287%)
[2026-05-15 10:33:43.327] [device] [info] [GenericDevice.cpp:60] Updating device state (LogicPro16/0x46CFE74A24F69820) from DSInitializing(msg=, progress=25.269498229196287%) to DSInitializing(msg=, progress=30.32339787503554%)
[2026-05-15 10:33:43.444] [device] [info] [GenericDevice.cpp:60] Updating device state (LogicPro16/0x46CFE74A24F69820) from DSInitializing(msg=, progress=30.32339787503554%) to DSInitializing(msg=, progress=35.377297520874805%)
[2026-05-15 10:33:43.561] [device] [info] [GenericDevice.cpp:60] Updating device state (LogicPro16/0x46CFE74A24F69820) from DSIniti

Note that the log file is not unintentionally truncated. It ends in the middle of what looks like a DSInitializing() process.

Please let me know if I can provide any additional information to help debug.

Thanks,

Liam

markgarrison · May 19, 2026, 3:46am

Hi @liam.ogletree and @dominic.styblo,

I’ve just sent both of you an early build of the software that was built with the latest version of Electron, for 2 reasons:

The crash is in electron, and this updates us from Electron 27 to Electron 41. If this is a GL issue, there is a chance that might just fix it.
When I build Electron 27 for arm64 Linux (we have a slight variation on a standard build) I did not add the debug symbols to our crash report server. I did do that for Electron 41. If it still crashes, it will be far easier for me to see the crashing electron stack trace.

Please post your replies here, rather than reply to the direct message - it will be easier for other folks here at Saleae to see it too.

Mark

liam.ogletree · May 19, 2026, 3:39pm

Hi @markgarrison,

I tested the early build you provided separately – it still crashes, but I can see additional console output, so I’m confident you should see more on your end.

My machine ID is unchanged (27e6406c-70ff-4a9d-9bcf-8ed876b52cc7), and I crashed the software 4 times between 10:20 AM CDT and 10:35 AM CDT. Just for clarity, I am now testing these builds on a desktop setup (not headless). The four crashes used the following command line options:

./logic2 --automation
./logic2
./logic2 --automation --no-sandbox --disable-gpu
./logic2

Here is the console output from just running ./logic2:

console-output.txt (33.7 KB)

Thanks,

Liam

markgarrison · May 19, 2026, 4:49pm

Hi Liam,

Thanks for the quick reply and for testing. I got the stack traces, but they are certainly incorrect. Every thread except one just shows the same 2 frames, __internal_syscall_cancel and __syscall_cancel_arch. The crashed thread, libuv-worker, is our best clue, but it only shows 2 frames as well: __pthread_kill_implementation twice.

The crash is the render process emitting SIGABRT, which helps. I think we should try to do 3 things:

Increase electron logging output
Collect a real core file locally, rather than relying on the minidumps our application is uploading
Try to reproduce this over here if possible.

Could you launch the software like so?

ulimit -c unlimited
export ELECTRON_ENABLE_LOGGING=1
./logic2 --disable-gpu --enable-logging=stderr --v=1 2>&1 logic-crash.txt

Then after the crash, check for a core file. The file is likely very large, if you can’t attach it easily to a support message (Contact Us | Saleae), let me know and I can email you a large file upload link.

You mentioned you’re testing this on your desktop, is this also a Raspberry Pi 4? Same image you linked above, or an image that included a full desktop environment? A link would be great. If there is an easy way for me to image a SD card and boot it up in either my Pi 4 or Pi 5, I’ll see if I can reproduce it. (I haven’t used my Pi for testing since a much earlier build, lately I’ve been using a VM on my Apple Silicon machine and WSL2 from my Arm64 Windows laptop. The last time I tested on a Pi I think I was using Ubuntu 24.10, because at the time the build didn’t support the Raspberry Pi OS (which it should now)

liam.ogletree · May 19, 2026, 6:56pm

Hi @markgarrison,

Here is the increased electron logging output:

logic-crash.txt (261.8 KB)

I am not seeing any core dumps generated by the crash. I’m verifying that ulimit -c indicates unlimited, and I get core dumps for other command line programs (e.g., cat followed by ^\ for quit). I’m not sure if there is a flag I can provide on the command line when running ./logic2 or if I need a different build. I suppose it’s also possible that whatever is causing Logic2 to crash isn’t dumpable.

Regarding reproducibility:

This is a Raspberry Pi 4 Model B with the following image (latest 64-bit release): https://downloads.raspberrypi.com/raspios_arm64/images/raspios_arm64-2026-04-21/2026-04-21-raspios-trixie-arm64.img.xz
For imaging an SD card, I’m also on an Apple Silicon machine and am using Raspberry Pi Imager (https://downloads.raspberrypi.com/imager/imager_latest.dmg) to image the SD card.

Thanks,

Liam

markgarrison · May 20, 2026, 5:34pm

Thanks @liam.ogletree,

I’m not sure if I missed this from previous logs, but this line was helpful: terminate called after throwing an instance of 'std::runtime_error*'

Unfortunately the log you already sent in (from ~/.config/Logic/logs) wasn’t flushed, which is unfortunate because that might have contained the exception string. This does indicate that the crash might be coming from our native code and not from electron/chromium (we do throw a lot of std::runtime_errors) however usually in these cases we get fantastic crash dumps.

That said, I checked again for crashes from your machine ID, and I found one unique error from 19th May 2026 11:48 am GMT-0700.

This is likely the same crash from your last run, since it crashes with an unhandled std::runtime_error.

The crash is cased by an mmap failure, which I think I’ve seen before.

    mAllocation = mmap( nullptr, mCapacity, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0 );
    if( mAllocation == MAP_FAILED )
    {
        throw new std::runtime_error( "mmap failed: " + std::to_string( errno ) );
    }

(unfortunately due to un-flushed logs, we don’t have that error number)

This code runs during session creation as we prepare collections to store recorded data. we reserve large sections of contiguous virtual memory, but don’t actually use it until needed. We generally assume that the virtual address space is infinite. I don’t recall off the top of my head, but I think the reservations are something like 64 gigs per channel. (The memory is not allocated, we just want to reserve linear address space for efficient operations later)

I suspect the problem here is that the virtual address space is smaller on your machine. I haven’t dug into this yet, but it seems likely we should be able to handle this, likely with pretty low impact.

In the short term, could you send me the output of all of these commands?

uname -a
getconf PAGESIZE
ulimit -a
cat /proc/self/limits
cat /proc/sys/vm/max_map_count
cat /proc/sys/vm/overcommit_memory
cat /proc/sys/vm/overcommit_ratio
grep -E 'VmPeak|VmSize|VmRSS|VmData|VmStk|VmExe|VmLib|VmPTE' /proc/self/status
wc -l /proc/self/maps

liam.ogletree · May 20, 2026, 5:59pm

Hi @markgarrison,

Thanks for digging into this. Here is the requested console output:

logletre@logletre-pi:~ $ uname -a
Linux logletre-pi 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux

logletre@logletre-pi:~ $ getconf PAGESIZE
4096

logletre@logletre-pi:~ $ ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) 0
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 13060
max locked memory           (kbytes, -l) 8192
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 13060
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited

logletre@logletre-pi:~ $ cat /proc/self/limits
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            8388608              unlimited            bytes
Max core file size        0                    unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             13060                13060                processes
Max open files            1024                 524288               files
Max locked memory         8388608              8388608              bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       13060                13060                signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us

logletre@logletre-pi:~ $ cat /proc/sys/vm/max_map_count
1048576

logletre@logletre-pi:~ $ cat /proc/sys/vm/overcommit_memory
0

logletre@logletre-pi:~ $ cat /proc/sys/vm/overcommit_ratio
50

logletre@logletre-pi:~ $ grep -E 'VmPeak|VmSize|VmRSS|VmData|VmStk|VmExe|VmLib|VmPTE' /proc/self/status
VmPeak:	    6396 kB
VmSize:	    6396 kB
VmRSS:	    2036 kB
VmData:	     432 kB
VmStk:	     132 kB
VmExe:	     188 kB
VmLib:	    2416 kB
VmPTE:	      40 kB

logletre@logletre-pi:~ $ wc -l /proc/self/maps
18 /proc/self/maps

Thanks,

Liam

markgarrison · May 20, 2026, 9:55pm

Ok, the root cause of this issue is that the Raspberry Pi OS Kernel is compiled with a 4K page size and 3 levels of translation tables. This results in a virtual address space limit of 512GB, much smaller than the near infinite available on typical x86_64 kernels that we’re used to.

github.com/raspberrypi/linux

Change default page table size to 4

opened 04:00PM - 04 Jun 21 UTC

PKizzle

**Describe the bug** [Google's tcmalloc](https://github.com/google/tcmalloc) as…sumes a page table size of 4 (which seems to be considered the default) to allocate heap and fails since the kernel is compiled with `CONFIG_PGTABLE_LEVELS=3` by default. **To reproduce** As example you could try to run the envoy proxy which uses tcmalloc under the hood. `docker run --rm envoyproxy/envoy:v1.17.0 --version` This will fail with a memory allocation error. **Expected behaviour** The heap allocation should not fail and enovy should print its version information. This can be achieved by setting `CONFIG_PGTABLE_LEVELS=4`. **Actual behaviour** The heap allocation fails leading to envoy not being able start up and fail with an error message. **System** ``` Raspberry Pi 4 Model B Rev 1.4 PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" Raspberry Pi reference 2020-08-20 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7252c154838ec5b4576f29c996ac8fe3750cae12, stage2 Linux raspberrypi-4 5.10.17-v8+ #1421 SMP PREEMPT Thu May 27 14:01:37 BST 2021 aarch64 GNU/Linux Revision : d03114 Model : Raspberry Pi 4 Model B Rev 1.4 Throttled flag : throttled=0x0 Camera : supported=0 detected=0 version 7d9a298cda813f747b51fe17e1e417e7bf5ca94d (clean) (release) (start) ``` **Logs** This is the error message you will receive from envoy / tcmalloc when kernel is compiled with `CONFIG_PGTABLE_LEVELS=3`: ``` external/com_github_google_tcmalloc/tcmalloc/system-alloc.cc:550] MmapAligned() failed (size, alignment) 1073741824 1073741824 @ 0x55867b9470 0x55867aba14 0x55867ab454 0x5586794e94 0x55867a8684 external/com_github_google_tcmalloc/tcmalloc/arena.cc:34] FATAL ERROR: Out of memory trying to allocate internal tcmalloc data (bytes, object-size) 131072 48 @ 0x55867b9780 0x5586794f10 0x55867a8684 ``` **Additional context** This is a conversation from the OpenJDK project which had to deal with the same situation: http://openjdk.5641.n7.nabble.com/ZGC-aarch64-Unable-to-allocate-heap-for-certain-Linux-kernel-configurations-td420728.html Basically their solution is to try allocating memory multiple times until it succeeds, which does not seem to be ideal. This is the excerpt from the [kernel documentation](https://www.kernel.org/doc/Documentation/arm64/memory.txt): ``` AArch64 Linux uses either 3 levels or 4 levels of translation tables with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit (256TB) virtual addresses, respectively, for both user and kernel. With 64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB) virtual address, are used but the memory layout is the same. ``` These are the open issues for [envoy](https://github.com/envoyproxy/envoy/issues/15235#issuecomment-850516622) and [tcmalloc](https://github.com/google/tcmalloc/issues/82)

Our general approach creates large virtual address reservations for every channel of every session (tab). (I don’t recall, but it’s probably about 64 GB per channel). the 4 default channels don’t quite explain the crash, so it seems likely that we’re reserving even more than that.

We’re already discussing what we could do to support this case, but whatever it is, it won’t be a quick. There are really only 2 short term viable options:

Switch to a distro (e.g. Ubuntu) that uses a kernel with either 4K pages and 4 levels of translation tables, or switch to a kernel with larger page sizes.
Re-compile Raspberry Pi OS kernel with this change.

This article actually explains the difference and has instructions on how to re-compile the Raspberry Pi OS kernel both locally on the Pi, as well as with cross compile from a more powerful x86_64 host: Running gVisor on Raspberry Pi 5: A Kernel Configuration Adventure | Nubificus The article is about gVisor, but you can ignore all that - the solution is the same.

I missed this issue because through most of the Arm64 support project, we didn’t support Raspberry Pi OS just due to glibc version reasons. After we updated our build system to reduce our library dependencies, I never went back and tested Raspberry Pi OS.

That also explains why none of our earlier testers reported this issue. They had all switched away from Raspberry Pi OS to get the early versions working, and never switched back.

This is unfortunate, as I was excited that our software would finally “Just work” on Raspberry Pi OS, given that it’s the default and most popular option for these boards.

We’ll need to re-think our approach if we want to get around the 512 GB virtual address space limit.

Topic		Replies	Views
Logic 2 crashed when capturing large SPI data Logic 2 Software	11	1572	August 17, 2023
Can't run on Arch Linux recently Logic 2 Software	23	1415	February 9, 2026
Crash on startup / openSUSE Tumbleweed Logic 2 Software	10	1459	January 9, 2022
Logic 2 Linux Memory Limitation Logic 2 Software	4	477	February 23, 2024
Memory limitation on Linux Logic 2 Software	9	1837	November 30, 2023

Crashing in Raspberry Pi Arm64 Linux Environment

Related topics