[SOLVED] Chromium based apps crash after some time

I’ve been noticing quite often that after some hours of use, chromium-based apps will start randomly crashing quite frequently. Examples include Vivaldi, Brave and VSCode.

For some context, I have the 11th gen framework and it’s plugged into a Caldigit TS3. The TS3 is outputting to 2 monitors, one with thunderbolt and one with HDMI. I use it for work, so it’s usually running a couple browsers, code editors and several docker containers.

I’ve tried searching the journal and dmesg, and the only thing that comes up is some message like elf_dynamic_array_reader.h(64)] tag not found related to vivaldi and occasionally something along the lines of vivaldi “consumed 1min 54sec of CPU Time”.

I’m not new to linux, but I’m a bit stumped. Any thoughts on what might be going on or what I could try?

EDIT: I’m using Ubuntu 20.04 with Xorg
MORE EDIT: My goto remediation is to restart the laptop, which fixes it for a while, but it’s pretty persistent.

Did you run a memtest to check if your RAM is okay?

@Anachron I have not yet, but I plan to do so when I can commit some time to it, it’s a good suggestion though!

Try disabling hardware acceleration for them

Good places to start:

  • Does this happen without the Caldigit TS3 isn’t connected (ideally testing during free time).

  • I could write a book on how often I see the words VSCode and crash while running other Chromium based software. It’s frustrating. I’d test to see if this happens when you run something like Firefox. If not, it’s the ol VSCode vs Chromium based software thing I’ve seen all over various Linux forums lately.

  • Disabling hardware acceleration is also worth trying while running Chromium based software and VSCode at the same time.

  • If with everything above, including this event still happening with Firefox while running VSCode, then I’d test the RAM.

@Matt_Hartley Thank you for these suggestions! I will give them each a try. I am interested in more context on the “vscode with chromium browser” issues as I’m not familiar with that one.

I’m a bit disappointed at the lack of good hardware acceleration support for linux and the framework, did this get better with the 12th gen cpu by any chance (to your knowledge)?

Ideally, when the distro allows for it (not a Framework shortcoming), it “should work.” But, we want to eliminate any likely candidates that may be causing the error in triaging this issue.

Once we trim things down and figure out where it’s having issues, we can then build things back up and address the issue head on when possible.

Oh man, “disappointed” was a heavy word, apologies for that. I love my framework (and have convinced several others at work to switch to them from MBPs :smile: )

1 Like

No worries, I get it. Tech can be frustrating when it’s not cooperating. :slight_smile:

Ok, so I tried an approach that might be working:
Previously I was doing thunderbolt to the caldigit, then from the caldigit I had 2 video outputs, one over thunderbolt and one over DP-to-HDMI active dongle.

I moved the HDMI to be directly connected to the framework (so 2 cables from the framework now) and things seem more stable, no browser crashes for an entire day.

Does this shed light on anything?

Yep, this is the recommended approach. Always direct connect and leave docks, etc, to USB duties. :slight_smile: It’s not a matter of speed, it’s a matter of how (insert dock/hub here) cooperates with the Framework.

Out of curiosity, is this a Framework limitation, a Linux limitation, a Caldigit TS3 limitation, or a protocol limitation? :slight_smile:

From my understanding all “parties” in that list establish claims that seem to indicate they “should all work”, but I’m wondering if it’s grounds for requesting a refund on the TS3 (since I bought it specifically for the promise of 1 cable docking).

Kernels, firmware and so forth all play a part. The short version is we cannot provide tech support we don’t have or make.

A a good rule of thumb with any device is less is more. Direct connections are always a win. Hubs and docks “should work” but I’ve seen stuff like this on my old XPS - docks are best suited for USB duties in my experience.

One could say this is a Linux limitation in that it’s constantly evolving (kernel updates, regressions, other unaccounted incompatibilities after an update).

Yeah makes sense, thanks for following up. Things are more stable with displays plugged directly into the laptop, but still get occasional full-machine lock ups that I haven’t been able to figure out. I appreciate your help though!

1 Like

Going to mark this as solved as it’s working using our recommended guidelines of direct connections. Appreciate the update. :slight_smile: