Bug 488551

haruna flickers between fullscreen and not fullscreen faster and DOESN'T CRASH if "Show menubar" disabled in settings

ALTERNATIVE STEPS TO REPRODUCE (ydotool needed)
1. open haruna (playing video or audio not needed)
2. click "Configure"
3. run "ydotool type --delay=9999 '                    '" as root asynchronously
4. click "Show menubar" checkbox (inside "Settings — Haruna" window)
5. wait until step 3 finishes

note: step 3 must finish after step 4

This happens on arch as well, in version 1.1.2.
I'd argue that the expected behaviour matches that of mpv instead of vlc (that being changing only once until the input is held), since this can cause problems for people sensitive to flickering.

Created attachment 180530 [details]
Stack trace

Reproduced with Haruna 1.3.3 (non Flatpak version) on:
* Manjaro
* Kernel 6.12.21-4-MANJARO
* X11
* Qt 6.9.0

If hardware decoding is disabled and the mouse is over the seekbar in fullscreen, pressing F three to four times quickly can be enough to make it crash.

(In reply to Thomas Bertels from comment #4)
> Created attachment 180530 [details]
> Stack trace

> If hardware decoding is disabled and the mouse is over the seekbar in
> fullscreen, pressing F three to four times quickly can be enough to make it
> crash.

Thanks for the backtrace.  Unfortunately the backtrace is incomplete and missing debug symbols for the following lines that we need to figure out exactly what's going wrong:

#7  0x00007f1948977dea in ??? () at /usr/bin/../lib/libQt6QuickTemplates2.so.6
#12 0x00007f1958c60f63 in ??? () at /usr/bin/../lib/libQt6Qml.so.6
#18 0x00007f19591b750d in ??? () at /usr/bin/../lib/libQt6Quick.so.6

Could you please install debug symbols and attach a new symbolicated backtrace generated by using `coredumpctl gdb` in a terminal window? See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl for details about how to do this. Thanks again!

*** Bug 504522 has been marked as a duplicate of this bug. ***

Created attachment 181569 [details]
gdb --command=THIS_FILE

I compiled https://github.com/qt/qtbase/tree/v6.9.0 and https://github.com/qt/qtdeclarative/tree/v6.9.0 and https://invent.kde.org/multimedia/haruna/-/commit/310a92f29cc3a4f2f30489eb6898f6d5a47ef40a with -O0 -ggdb3 on kde neon

haruna is laggy but that makes crashing easier (don't have spam click "Show menubar" fast)

I crash haruna like this:
1. run `gdb --command=gdb.txt` (gdb.txt in attachment)
2. click "Settings'
3. turn on "Show menubar" (left click) (it was off all times I opened haruna `gdb --command=gdb.txt` with after crash)
4. turn off "Show menubar" (left click)
5. turn on "Show menubar" (left click) (immediately after step 4, easier if turn off g++ optimizations for qtdeclarative)
6. haruna crashes (you don't get to see check inside "Show menubar" checkbox)

backtrace is inconsistent

Created attachment 181570 [details]
common crash location

Created attachment 181571 [details]
rare crash location

Created attachment 181572 [details]
extra rare crash location (happened only once)

if I:
1. run `gdb --command=gdb.txt`
2. click "Settings'
3. turn on "Show menubar" (left click) (it was off all times I opened haruna `gdb --command=gdb.txt` with after crash)
4. set breakpoint on https://github.com/qt/qtdeclarative/blob/v6.9.0/src/quicktemplates/qquickmenu.cpp#L1390 (`b qquickmenu.cpp:1390` gdb command)
5. turn off "Show menubar" (left click)
6. wait 3 seconds
7. turn on "Show menubar" (left click)
8. BREAKPOINT HIT
9. run `x/a d->contentItem` gdb command

I see `0x555559943890:	0x7ffff3378be8 <_ZTVN11QQmlPrivate11QQmlElementI14QQuickListViewEE+16>`.

10. delete breakpoint (`del` gdb command)
11. continue (`c` gdb command)
12. haruna doesn't crash

if I:
1. run `gdb --command=gdb.txt`
2. click "Settings'
3. turn on "Show menubar" (left click) (it was off all times I opened haruna `gdb --command=gdb.txt` with after crash)
4. set breakpoint on https://github.com/qt/qtdeclarative/blob/v6.9.0/src/quicktemplates/qquickmenu.cpp#L1390 (`b qquickmenu.cpp:1390` gdb command)
5. turn off "Show menubar" (left click)
6. turn on "Show menubar" (left click) (immediately after step 5)
7. BREAKPOINT HIT
8. run `x/a d->contentItem` gdb command

I see `0x55555952a790:	0x55555952bb00`

9. continue (`c` gdb command)
10. haruna crashes

haruna crashes because d->contentItem pointer points to invalid QQuickItem (first 8 bytes of a valid QQuickItem is address of vtable + 16)

Created attachment 181609 [details]
double right click crash

I can crash haruna (with unoptimized qt libs) by just double right clicking in black area (middle).

Created attachment 181673 [details]
gdb_with_log.txt (usage: `gdb --command=gdb_with_log.txt`)

I figured out the reason why haruna crashes on fast double right click

note: QQmlElement_42, QQmlElement_41, QQuickMenu_31 are made up names by python code inside gdb_with_log.txt

QQmlObjectCreator::clear ( https://github.com/qt/qtdeclarative/blob/v6.9.0/src/qml/qml/qqmlobjectcreator.cpp#L1653 ) destroys:

1. QQmlPrivate::QQmlElement<QQuickListView> QQmlElement_42
2. QQmlPrivate::QQmlElement<QQuickListView> QQmlElement_41
3. QQuickMenu QQuickMenu_31

but QQuickMenu destructor in step 3 depends on QQmlElement_42 existing (d->privateItem is QQmlElement_42, https://github.com/qt/qtdeclarative/blob/v6.9.0/src/quicktemplates/qquickmenu.cpp#L1403 )

haruna doesn't crash on slow double right click (wait between clicks) because different code does (actually more like schedules) the destruction correctly ( https://github.com/qt/qtdeclarative/blob/v6.9.0/src/quick/items/qquickloader.cpp#L341 )

Created attachment 181674 [details]
fast_log.txt

how fast_log.txt was generated:

1. run `gdb --command=gdb_with_log.txt`
2. wait until gdb stops printing stuff
3. move mouse to point inside haruna window back area
4. right click
5. move mouse to different point inside haruna window back area that won't be on menu
6. right click
7. haruna crashes and I see `Thread 1 "haruna" received signal SIGBUS, Bus error.` printed by gdb
8. run `generalize_log /tmp/fast_log.txt` in gdb

note: I use kwin_wayland on kde neon
note: steps 4, 5, 6 need to happen fast

Created attachment 181675 [details]
slow_log.txt

how slow_log.txt was generated:

1. run `gdb --command=gdb_with_log.txt`
2. wait until gdb stops printing stuff
3. move mouse to point inside haruna window back area
4. right click
5. move mouse to different point inside haruna window back area that won't be on menu
6. wait for menu
7. right click
8. ctrl+c gdb
9. run `generalize_log /tmp/slow_log.txt` in gdb

note: I use kwin_wayland on kde neon
note: steps 4, 5 need to happen fast

https://bugreports.qt.io/browse/QTBUG-137160