Logic 2.4.10 or newer is crashing on Ubuntu 22.04 LTS

I’ve been using the 2.4.10 for a while on my Ubuntu 22.04 LTS without any problem.

Today, after maybe 1,5 months not using it, I tried to run and I am getting this problem:

/tmp$ ./Logic-2.4.10-linux-x64.AppImage 
/tmp/.mount_Logic-nqI8Jc /tmp
/tmp
Environment
  Executable path: /tmp/.mount_Logic-nqI8Jc/Logic
  Executable directory: /tmp/.mount_Logic-nqI8Jc
  Original working directory: /tmp
  Current working directory: /tmp/.mount_Logic-nqI8Jc
  Process ID: 119690
Crash reporting enabled. Machine ID: 9eddda9b-c2e5-4e19-be51-9870821ed9f2
@saleae/electron/main: renderer process died { reason: 'crashed', exitCode: 133 }
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:870:5498
Remote event names: close

When I run, the software can launch, I can configure the channels, analyzers, etc, but when I click on “Start” (the green play icon), then it crashes.

I have tested with newer version 2.4.13, and same problem is seen.

@cassianocampes Sorry for the trouble with this! This looks like a specific error in 2.4.10 that we have since fixed.

You mentioned that you saw the same crash and error in 2.4.13. As such, can you also share the output of running 2.4.13?

@timreyes here is the log for 2.4.13:

~/Downloads$ ./Logic-2.4.13-linux-x64.AppImage 
/tmp/.mount_Logic-M7Awy1 ~/Downloads
~/Downloads
Environment
  Executable path: /tmp/.mount_Logic-M7Awy1/Logic
  Executable directory: /tmp/.mount_Logic-M7Awy1
  Original working directory: /home/cassiano/Downloads
  Current working directory: /tmp/.mount_Logic-M7Awy1
  Process ID: 354668
Crash reporting enabled. Machine ID: 9eddda9b-c2e5-4e19-be51-9870821ed9f2
@saleae/electron/main: renderer process died { reason: 'crashed', exitCode: 133 }
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:872:5498
Remote event names: close

It looks like the same problem.

@cassianocampes Thanks for sharing that information. Can you confirm if the crash also occurs when the Logic analyzer is disconnected (i.e. when running a simulation capture)?

I’m curious to know if the crash only pertains to a connected device, or if it also crashes on simulation captures as well. This might help narrow down our debugging efforts over here.

Hello! Wow. I also keep coming across exactly the same 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”)
I have Fedora 39. This happens to me when I press “restart” so that the analyzer decrypts the data received from the usb stream. (Logic v2.4.13)

Hello @timreyes here are some more information that could help you.

At first, I launched the Logic software with no Analyzer connected (no USB connected).
So, the screen shows:
“Connect Saleae Device OR Try a demo device / Open a capture”.

So, I click on “Try a demo device” and I select the “Logic 8”. So, the software opens the capture screen normally.
Thus, I click on the “Play” button, to start capturing the demo and it works fine as shown in below image.

UPDATE:

Then, I saved this capture, and relaunch the software, this time I select “Open a capture”, and I opened the demo I just captured. It also works fine.

Ah, I discovered the problem, at least, I could make it work again.

So basically, I was using the Analyzer in a USB HUB connected to my computer. My USB HUB is a USB3.0 High Speed Hub. When I connect to it, the problem happens.

But, if I connect the Analyzer directly on the USB port of my computer, then it works fine.

So, I guess the problem is narrowed down to when someone uses a USB Hub (my case) then the crash occurs. I just did another test by reducing the sampling hate to the lowest possible (25k) and the crash still occurs.

@cassianocampes, thanks for all of the details!

Can you let me know which device you are using? (Logic 8, Logic Pro 8, or Logic Pro 16)

Also, you mentioned that the hub was “USB3.0 High Speed Hub”. Could you double check that? USB High Speed refers to USB 2.0 speed, where USB Super Speed refers to USB 3.0 speed. Most USB 3.0 Super Speed hubs have blue USB ports, but hopefully the hub will just say.

This is a very odd crash. What makes it more unusual is that I was able to look up crash reports based on the machine ID in your log output, and I found two types of of crashes from version 2.4.13:

8 memory related crashes.
16 python related crashes.

The memory crashes are not caused by running out of memory, I believe, but caused by a bug in our software that attempts to do very large single allocations (over 2GB in a single allocation). We recently discovered an embarrassing bug where the slower you record, the more memory the software allocates. We never noticed this because we rarely test the lowest sample rates of our products. It’s possible if you are connecting a Logic Pro 8 or Logic Pro 16 through a USB 2.0 hub, then the software will limit you to lower sample rates. In this case, you might be using a sample rate so low that it causes a crash.

That said, in our testing, the only reliable way we could reproduce the crash was to record just 1 digital channel at 1 MS/s.

Could you reproduce the crash for us using the USB hub, and take note of the exact capture settings you are using before the crash? Specifically, the number of analog or digital channels enabled, and the sample rate used for analog and digital recording.

Then, could you test the same capture settings when the logic analyzer is connected directly to your computer, to see if it still crashes? That would help us determine if the crash you’re seeing is the memory bug we recently identified. (We’ll get that fixed soon)

The other 16 Python related crashes is something we’ve seen a LOT of (It’s by far our #1 Linux crash) however we’ve never heard a single report from a customer about it. We think that it’s a python subprocess that’s crashing, and it’s not actually interfering with the application. Our application uses python in order to run measurements and high-level analyzers, and we include our own python runtime with the software - it should not interfere with whatever python you may or may not have installed on your system. The stack traces from these crashes would suggest its crashing on launch, not when you start a capture, so we’re pretty sure it’s a red herring.

Here is a picture of the HUB I just mentioned.

About my computer configurations, here it is:

And here is Linux kernel version:

On a next post I will share the test logs you requested.

Could you reproduce the crash for us using the USB hub, and take note of the exact capture settings you are using before the crash? Specifically, the number of analog or digital channels enabled, and the sample rate used for analog and digital recording.

1. Setup using the USB Hub

  • USB Hub connected to my computer on a USB 3.0 port
  • Analyzer connected to the USB Hub

Here, I simply configure to capture from Async Serial, BR 115200:

Here is the sampling rate config:

Then, I click to start capturing, and it crashes:

Then, could you test the same capture settings when the logic analyzer is connected directly to your computer, to see if it still crashes? That would help us determine if the crash you’re seeing is the memory bug we recently identified. (We’ll get that fixed soon)

2. Setup using USB directly from computer

  • Analyzer connected directly in the USB 3.0 port of my computer

I kept the same config as previous example, related to Async Serial config, and sampling rate, so I ran the capture and it crashed:

Obs.: The USB cable size is about 1 meter long I am using it in all tests here.

Thanks for the additional data.

  1. That looks like an original Logic! When and where did you get that? We discontinued that product about 10 years ago.

  2. Two channels at 500 kS/s definitely explains the crash, that would trigger the low data rate crash I mentioned. Try raising the sample rate to 2 MS/s or faster. Generally, I recommend running at the maximum rate, as long as you don’t get USB timeout errors. Even then, I would recommend lowering the sample rate one or two levels.

I don’t think the USB hub should be causing the crash, I think it’s purely a matter of selecting a higher sample rate.

We’ll also get that fixed fairly soon.

  1. I bought it from a regular store that sells electronic stuff, around 2019~2020, not sure exactly.
  • I tested again, by connecting the Analyzer directly in the PC’s USB 3.0 port, and at 1MS/s or more, it works fine.
  • I tested again, by connecting the Analyzer on the USB Hub, and I can only select up to 500kS/s or less, and as you mentioned, this causes the crash.

@cassianocampes Thanks for the additional information. The bug that Mark described is still on our backlog to fix.

I did want to dig into the comment you provided below.

Do you mean that, when connecting on the USB hub, the options above 500KS/s are not selectable? For example, are they grayed out in the software, or are they missing?

Hello, here is a print of the speed options when I connect the Analyzer with the USB HUB:

And here is a print of the speed options when I connect the Analyzer directly:

So, on the first, only up to 500kS/s down to 25kS/s is possible while the other is up to 24MS/s down to 25kS/s.

@cassianocampes Oh strange! I don’t think I’ve ever seen sampling rates missing like that before! I just tested this on my end through a USB hub and I wasn’t able to reproduce the missing sampling rates.

Can you confirm if your device is the Saleae Logic pictured below (the one with 9-pins in front)?

Also, as a quick debugging exercise, are you able to access the higher sampling rates through your USB hub when using our legacy Logic 1.2.40 software below?

Please note that the version above has been long obsolete. Having said that, I’m mainly curious if this may be a bug specific to our current Logic 2 software, and this test may help us narrow down on the source of the issue.