Trying to make sense of a QSGRenderThread Segmentation fault

Diracsbracket

Hi.
I have a PathView with a delegate that includes a simple QQuickPaintedItem-derived type element that paints a QPixmap for each. This type has a pixmap property to set the internal QPixmap member.

So far, this works as desired.

But then, I tried to add the following functionality: When the image is clicked, a new view is pushed to the StackView that uses the same QQuickPaintedItem-derived type to display a large-scale version of the same pixmap.

After that large-scale image is shown however, the program crashes 100% of the time, although not always after the same delay.

GDB shows the following backtrace:

Thread 16 "QSGRenderThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa30042e0 (LWP 8789)]
v3d_bo_map (bo=0x0) at ../src/gallium/drivers/v3d/v3d_bufmgr.c:535
535     ../src/gallium/drivers/v3d/v3d_bufmgr.c: No such file or directory.
(gdb) backtrace
#0  0xb0f8f0b8 in v3d_bo_map (bo=0x0) at ../src/gallium/drivers/v3d/v3d_bufmgr.c:535
#1  0xb0f95fd0 in v3d_cl_ensure_space (cl=cl@entry=0xa038e9ac, space=116, space@entry=1878955684, alignment=alignment@entry=32)
    at ../src/gallium/drivers/v3d/v3d_cl.c:53
#2  0xb0f9e9a4 in v3d_emit_gl_shader_state (info=0xa300320c, v3d=0x123f960) at ../src/gallium/drivers/v3d/v3dx_draw.c:359
#3  0xb0f9e9a4 in v3d_draw_vbo (pctx=0x123f960, info=0xa300320c) at ../src/gallium/drivers/v3d/v3dx_draw.c:759
#4  0xb0670cec in u_vbuf_draw_vbo (mgr=<optimized out>, info=info@entry=0xa3003420) at ../src/gallium/auxiliary/util/u_vbuf.c:1451
#5  0xb0641d9c in cso_draw_vbo (cso=<optimized out>, info=info@entry=0xa3003420) at ../src/gallium/auxiliary/cso_cache/cso_context.c:1705
#6  0xb0bb3418 in st_draw_vbo
    (ctx=ctx@entry=0x10cd3a0, prims=<optimized out>, nr_prims=nr_prims@entry=1, ib=0x0, index_bounds_valid=index_bounds_valid@entry=1 '\001', min_index=<optimized out>, min_index@entry=0, max_index=<optimized out>, max_index@entry=3, tfb_vertcount=0x0, stream=0, indirect=0x0)
    at ../src/mesa/state_tracker/st_draw.c:268
#7  0xb0c58ea8 in _mesa_draw_arrays (drawID=1, baseInstance=2965737340, numInstances=1, count=4, start=0, mode=6, ctx=0x10cd3a0)
    at ../src/mesa/main/draw.c:374
#8  0xb0c58ea8 in _mesa_draw_arrays (ctx=0x10cd3a0, mode=6, start=0, count=4, numInstances=1, baseInstance=0, drawID=0) at ../src/mesa/main/draw.c:351
#9  0xb0c58f7c in _mesa_DrawArrays (mode=6, start=0, count=4) at ../src/mesa/main/draw.c:531
#10 0xb160b8dc in  () at /lib/arm-linux-gnueabihf/libglapi.so.0

What is happening here?

kshegunov

QPixmap isn't reentrant, use QImage.

Diracsbracket

Thanks @kshegunov

QPixmap isn't reentrant, use QImage.

After more testing, the problem I am experiencing also happens after pushing a blank Item onto the StackView, so is not related to reusing the pixmap it seems.

It seems to have something to do with garbage collection, because as long as I don't push another page on top a PathView page, I works correctly and does not crash. It also happens when I replace all images by Image elements.

kshegunov

@Diracsbracket said in Trying to make sense of a QSGRenderThread Segmentation fault:

After more testing, the problem I am experiencing also happens after pushing a blank Item onto the StackView, so is not related to reusing the pixmap it seems.

Provide a minimal example reproducing this and do tell the versions of Qt, the compiler and the OS.

PS.
Did you remove any and all pixmaps?

Diracsbracket

Thanks, @kshegunov

Provide a minimal example reproducing this and do tell the versions of Qt, the compiler and the OS

I could not reproduce the crashes with a minimal example on Pi4 with PiOS, but I have finally isolated the source of the problem.

My QML program instantiates a QQuickPaintedItem-derived element that intermittently draws an animated graph in the window background. This element is reparented to certain pages of the StackView when they become the active item.

The crashes occurred because I forgot to disable that graph element before pushing another item on the stack. After the graph's timer would kick in, it would attempt to draw into a now inactive stack page, which apparently causes the crash.

However, in a minimal QML example for instance, I have tried updating a non-active page of a StackView using a QML timer on that page, and that seems to work to update a QML Text delegate. I guess that it works with Scene Graph-based elements but not with QQuickPaintedItem-derived elements?

kshegunov

Just out of curiosity, please, would you answer my two inquiries:

@kshegunov said in Trying to make sense of a QSGRenderThread Segmentation fault:

versions of Qt, the compiler and the OS

@kshegunov said in Trying to make sense of a QSGRenderThread Segmentation fault:

Did you remove any and all pixmaps?

Diracsbracket

@kshegunov
I tried this with Qt 5.15.2 on a Debian Buster VM build host, cross-compiling for Raspberry Pi 4.

Build host:

uname -a
Linux debian 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux

PiOS:

pi@raspberrypi:~$ uname -a
Linux raspberrypi 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux

Cross-compiler:

/bin/arm-linux-gnueabihf-g++ --version
arm-linux-gnueabihf-g++ (Debian 8.3.0-2) 8.3.0

I did indeed try by removing all pixmap usage at the QML side, replacing them with dummy a Image instead, but that did not resolve the problem.

For info, I also tried obtaining more info by enabling gcc's address sanitation option, but that gave no more info than already provided by gdb :

AddressSanitizer:DEADLYSIGNAL
=================================================================
==4981==ERROR: AddressSanitizer: SEGV on unknown address 0x00000008 (pc 0xabc8e0b8 bp 0xa1542918 sp 0x991fdd98 T15)
==4981==The signal is caused by a READ memory access.
==4981==Hint: address points to the zero page.
    #0 0xabc8e0b7 in v3d_bo_map ../src/gallium/drivers/v3d/v3d_bufmgr.c:534

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ../src/gallium/drivers/v3d/v3d_bufmgr.c:534 in v3d_bo_map
Thread T15 (QSGRenderThread) created by T0 here:
    #0 0x6cbc45 in __interceptor_pthread_create (/usr/local/bin/umplayer+0x20bc45)
    #1 0xb6f25fff  (<unknown module>)

==4981==ABORTING
04:48:48: Application finished with exit code 1.

kshegunov

@Diracsbracket said in Trying to make sense of a QSGRenderThread Segmentation fault:

I did indeed try by removing all pixmap usage at the QML side, replacing them with dummy a Image instead, but that did not resolve the problem.

I specifically asked because of this:

My QML program instantiates a QQuickPaintedItem-derived element

This trace stinks of a race condition, which is why I requested you provide an MRE. You not being able to reproduce it, makes me lean into that direction even more. I was entertaining the possibility of a bug, though, hence my "curiosity".

I guess that it works with Scene Graph-based elements but not with QQuickPaintedItem-derived elements?

There's no difference. QtQuick is the scene graph frontend.