2410044_en-US

[#1]

i.MX8MP - Weston crash with Vivante 6.4.11.p4.x when using Qt OpenGL / large EGL render targets

Hello NXP Support,

we are investigating a reproducible graphics issue on an i.MX8MP platform.

Working configuration

• Yocto Scarthgap
• Kernel: 6.6.52
• Vivante stack: 6.4.11.p2.x
• Weston 14.0.2.imx
• Qt 6.8.3

Result:

• Qt Quick works
• QOpenGLWindow works
• No crashes

Failing configuration

• Yocto Wrynose
• Kernel: 6.18.20
• Vivante stack: 6.4.11.p4.4 and 6.4.11.p4.6
• Weston 14.0.2.imx
• Qt 6.8.3 and 6.8.4

Result:

• QQuickWindow crashes
• QOpenGLWindow crashes
• Weston crashes with SIGSEGV
• We also observed memory corruption symptoms:

malloc(): unaligned tcache chunk detected

and occasional crashes of unrelated processes after the graphics failure.

---

Qt is probably not the root cause

Initially the issue looked like a Qt Quick problem.

However, we reduced the test case to a minimal:

QOpenGLWindow

without QML, Scene Graph, QRhi, textures, or custom rendering.

The failure still occurs.

---

Native EGL tests

A simple native Wayland/EGL/GLES3 application is stable:

wl_egl_window
eglCreateContext
glClear
eglSwapBuffers

even when resizing up to:

1920x1080

for hours.

---

Additional native EGL tests

We created a native Wayland/EGL/GLES3 test using:

• texture allocation
• FBO creation
• render-to-texture
• glFramebufferTexture2D()
• glBlitFramebuffer()
• eglSwapBuffers()

The following sizes pass successfully:

500x500
640x480
800x480
900x540
1024x600

The issue starts appearing with larger render targets such as:

1280x720
1280x800

---

Weston behavior

After launching the OpenGL application, Weston crashes:

weston.service: Main process exited
status=11/SEGV

The Qt application then reports:

The Wayland connection broke.
Did the Wayland compositor die?

indicating that Weston crashes first.

---

Vivante userspace differences

The following libraries differ between the working and failing systems:

libGAL.so
libEGL.so
libGLESv2.so

The issue is reproducible with both:

6.4.11.p4.4
6.4.11.p4.6

while the older:

6.4.11.p2.x

works on the 6.6 kernel.

---

Questions

1. Are there any known issues in Vivante 6.4.11.p4.x related to:

   • Weston
   • Wayland-EGL
   • FBOs
   • glBlitFramebuffer()
   • large render targets

2. Are there known regressions between p2.x and p4.x?

3. Are there recommended debug options for:

   • galcore
   • libGAL
   • libgbm_viv
   • Weston buffer import paths

Any guidance would be greatly appreciated.

I attached a simple test app that can reproduce the crash on Kernel 6.18.20 with Vivante stack: 6.4.11.p4.4 and 6.4.11.p4.6

Re: i.MX8MP - Weston crash with Vivante 6.4.11.p4.x when using Qt OpenGL / large EGL render targets

I did further investigations.

Kernel 6.6.52 with Vivante p6.4.11.p4.4 -> works

Kernel 6.18.20 with Vivante p6.4.11.p4.4 -> crashes

The findings have now clearly worsened:

A direct resize from 500x500 to 1024x600 is already enough to cause a crash.
The crash occurs in the OpenGL path, immediately after a swapchain size change.
At the same time, the systemd-journal SEGV occurs again.
This is a strong indication of memory corruption in the GL/Wayland/Vivante stack, not just an app error.

Current Status of the Hypothesis

It's not just 1280x720 that's critical.
Rather, the decisive factor is the direct "Reconfigure" jump followed by "Present."
Sequential, smaller resizes are significantly more robust than a direct jump.
The software backend remains stable, confirming that the problem lies in the hardware-GL path.

Re: i.MX8MP - Weston crash with Vivante 6.4.11.p4.x when using Qt OpenGL / large EGL render targets

Hello,

A Vivante/galcore or buffer-management issue than a Qt problem, especially since the native EGL test also triggers it and Weston is the first process to crash. The fact that it starts with larger render targets and only happens with the p4.x stack is particularly interesting. I’d compare the p2 and p4 GAL/GBM changes and enable galcore/Weston debugging around buffer allocation and import.