Crash on launch during Chromium GPU initialization (GBM/Vulkan fallback)

[InTimeTechnologies]

OS: Ubuntu
I installed Zeal using the sudo apt install zeal command.
It launched from the start menu successfully once, but never a second time.
I launched Zeal from the terminal from the terminal. Below is what I got:

zeal
zeal.core.applicationsingleton: Singleton ID: hltFqz9aCDOwaAQesqn_G324AqLHh3IY62bXINMT_y8
zeal.core.applicationsingleton: Starting as a primary instance. (PID: 15401)
GBM is not supported with the current configuration. Fallback to Vulkan rendering in Chromium.
malloc(): invalid size (unsorted)
Aborted (core dumped)

I looked into this a while back and concluded Zeal was somehow loading the wrong Qt .so files.
I was able to fix this a while back by building Zeal from source.
I recently re-flashed my OS and do not feel like going through the hassle again.

Note to developers:
Try rebuilding Zeal with a brand new flashed Ubuntu OS with no previously installed packages. I think this would help spot where the issue is.

[trollixx]

Can you procure a stack trace? Otherwise, it's impossible to determine what happened.

[trollixx]

So, Ubuntu crash tracker has a bunch of similar issues. I think disabling hardware rendering should address this class of errors. I am looking into an automatic way to detect such crashes and revert to software rendering, see #1692.

Below is the Claude's summary of what is happening. Please try the suggested solution.

The malloc(): invalid size (unsorted) error indicates heap corruption — the malloc metadata is already damaged before Zeal's code runs. Based on Ubuntu crash reports with the same signature, this happens during GPU driver initialization (NVIDIA or Mesa/Intel) inside QtWebEngine/Chromium, before Zeal gets a chance to do anything meaningful.

The heap corruption originates in the GPU driver or Chromium's GPU initialization code. Building from source likely works around it because the build links against a different set of Qt/Chromium libraries than the distro package.

As a workaround, try running with software rendering:

• QT_OPENGL=software zeal
• QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu" zeal

[DuilioPerez]

So, Ubuntu crash tracker has a bunch of similar issues. I think disabling hardware rendering should address this class of errors. I am looking into an automatic way to detect such crashes and revert to software rendering, see #1692.

Below is the Claude's summary of what is happening. Please try the suggested solution.

The malloc(): invalid size (unsorted) error indicates heap corruption — the malloc metadata is already damaged before Zeal's code runs. Based on Ubuntu crash reports with the same signature, this happens during GPU driver initialization (NVIDIA or Mesa/Intel) inside QtWebEngine/Chromium, before Zeal gets a chance to do anything meaningful.

The heap corruption originates in the GPU driver or Chromium's GPU initialization code. Building from source likely works around it because the build links against a different set of Qt/Chromium libraries than the distro package.

As a workaround, try running with software rendering:

• QT_OPENGL=software zeal
• QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu" zeal

I have a similar issue in Termux, but mine is because my GPU drivers are experimental. So screen is redered totally black. It could be more usefull if in a future version you add a configuration option to toggle it

[DuilioPerez]

In my case this is with hardware rendering (default):

And this is with software rendering:

[trollixx]

@DuilioPerez in your case Zeal at least starts :) I'd like to add some checks that would automatically switch to software rendering but haven't done full research on the subject yet. A manual switch is already available with env vars, but I will also add a config option for #1692.

[DuilioPerez]

@DuilioPerez in your case Zeal at least starts :) I'd like to add some checks that would automatically switch to software rendering but haven't done full research on the subject yet. A manual switch is already available with env vars, but I will also add a config option for #1692.

Yes, a config option is more comfortable. Those issues with Hardware Acceleration are very common in Linux.