@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.