[Fedora] Crash in [@ WaylandBuffer::IsAttached()]
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | unaffected |
firefox-esr140 | --- | unaffected |
firefox142 | --- | affected |
firefox143 | --- | affected |
firefox144 | --- | affected |
People
(Reporter: aryx, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
Attachments
(2 files)
18 crashes from 16 installs of Firefox 142.0 20250818081258 on Fedora 42.
Crash report: https://crash-stats.mozilla.org/report/index/2d7910f1-e521-4c6c-a513-a83890250821
MOZ_CRASH Reason:
ElementAt(aIndex = 0, aLength = 0)
Top 10 frames:
0 firefox <name omitted> /usr/src/debug/firefox-142.0-1.fc42.x86_64/objdir/dist/include/mozilla/Assertions.h:248
0 firefox <name omitted> /usr/src/debug/firefox-142.0-1.fc42.x86_64/objdir/dist/include/mozilla/Assertions.h:381
0 firefox mozilla::detail::InvalidArrayIndex_CRASH(unsigned long, unsigned long) /usr/src/debug/firefox-142.0-1.fc42.x86_64/mfbt/Assertions.cpp:77
1 libxul.so ElementAt /usr/src/debug/firefox-142.0-1.fc42.x86_64/xpcom/ds/nsTArray.h:1225
1 libxul.so mozilla::ArrayIterator<(anonymous namespace)::ChildProcessInfo const&, nsTArr... /usr/src/debug/firefox-142.0-1.fc42.x86_64/objdir/dist/include/mozilla/ArrayIterator.h:107
2 libxul.so mozilla::widget::WaylandBuffer::IsAttached() const /usr/src/debug/firefox-142.0-1.fc42.x86_64/widget/gtk/WaylandBuffer.cpp:94
3 libxul.so operator()<RefPtr<mozilla::widget::WaylandBufferSHM> > /usr/src/debug/firefox-142.0-1.fc42.x86_64/widget/gtk/WindowSurfaceWaylandMultiBuffer.cpp:369
3 libxul.so RemoveElementsBy<mozilla::widget::WindowSurfaceWaylandMB::CollectPendingSurfa... /usr/src/debug/firefox-142.0-1.fc42.x86_64/objdir/dist/include/nsTArray.h:2570
3 libxul.so mozilla::widget::WindowSurfaceWaylandMB::CollectPendingSurfaces(mozilla::deta... /usr/src/debug/firefox-142.0-1.fc42.x86_64/widget/gtk/WindowSurfaceWaylandMultiBuffer.cpp:368
3 libxul.so mozilla::widget::WindowSurfaceWaylandMB::Lock(mozilla::gfx::IntRegionTyped<mo... /usr/src/debug/firefox-142.0-1.fc42.x86_64/widget/gtk/WindowSurfaceWaylandMultiBuffer.cpp:195
Comment 1•2 months ago
|
||
Hi Stransky,
This specific line is a range-based for-loop. [1]
The backtrace shows it try to access the element at 0 while the length of the array is 0.
It should not happen on range-based for-loop. I am wondering if this function has been called on multiple threads.
Updated•2 months ago
|
Comment 2•2 months ago
|
||
Do you mean this one - WindowSurfaceWaylandMB::CollectPendingSurfaces() ?
https://searchfox.org/firefox-main/rev/d683b2b2ed86192b3a87150c21fc51ba02a93142/widget/gtk/WindowSurfaceWaylandMultiBuffer.cpp#366
So it may be a problem with mPendingBuffers array, right? WindowSurfaceWaylandMB::Lock() is the only place where CollectPendingSurfaces() is called and it's under lock.
Updated•2 months ago
|
Comment 3•2 months ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #2)
So it may be a problem with mPendingBuffers array, right? WindowSurfaceWaylandMB::Lock() is the only place where CollectPendingSurfaces() is called and it's under lock.
If there is no concrete suspected path for a race, I'd recommend to switch to using MOZ_GUARDED_BY
instead of passing aProofOfLock
as that is both stronger in enforcing to see the right mutex being locked and cheaper. Doing this kind of refactoring can also help to eventually see the problematic path due to needed changes. See also https://firefox-source-docs.mozilla.org/xpcom/thread-safety.html for some examples.
Comment 4•29 days ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #2)
Do you mean this one - WindowSurfaceWaylandMB::CollectPendingSurfaces() ?
https://searchfox.org/firefox-main/rev/d683b2b2ed86192b3a87150c21fc51ba02a93142/widget/gtk/WindowSurfaceWaylandMultiBuffer.cpp#366
https://searchfox.org/firefox-main/rev/302639e599957123f8845cf7655ec10f479f2da2/widget/gtk/WaylandBuffer.cpp#94
The crash happens here. Multiple functions access mBufferTransactions
. Some of them may not protected, or protected by different lock.
Introducing a mutex and MOZ_GUARDED_BY
should be a safe option.
Updated•24 days ago
|
Comment 5•23 days ago
|
||
Encountered that. What info is needed?
Comment 6•23 days ago
|
||
Please run on terminal with MOZ_LOG="WidgetWayland:5" env variable, make it crash and attach the log here. For instance as:
MOZ_LOG="WidgetWayland:5" firefox > log.txt 2>&1
and attach log.txt file here.
Thanks.
Updated•23 days ago
|
Comment 7•22 days ago
|
||
Running with logs. However the crashes are unpredictable and intermittent and it may take some time.
Comment 8•22 days ago
|
||
I was able to reproduce the crash again, this time after running for 6 minutes. Crash report from the session: https://crash-stats.mozilla.org/report/index/6fe11c77-a2db-48f1-b3af-d3dc30250925. The full log is 67MB but due to bugzilla limitations I have only uploaded the last 10MB.
The crash happened another time 30 minutes earlier, after a longer session: https://crash-stats.mozilla.org/report/index/bp-7d9a30ba-801b-4a1d-bfac-872f60250925. (I don't have the wayland log for that one)
firefox version: 143.0.1
Thanks for your help!
about this system:
Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2
Kernel Version: 6.16.7-200.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 20 × Intel® Core™ i5-14600K
Memory: 32 GiB of RAM (31.1 GiB usable)
Graphics Processor 1: AMD Radeon RX 6700 XT
Graphics Processor 2: Intel® Graphics
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7D43
System Version: 1.0
Comment 9•22 days ago
|
||
These are last 9,000,000 lines of the log prior to the crash in zstd.
Comment 10•22 days ago
|
||
Cool, Thanks, will look at it.
Updated•22 days ago
|
Comment 11•22 days ago
|
||
Looks like Bug 1979106 - can you try latest nightly?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Thanks.
Updated•22 days ago
|
Comment 12•22 days ago
|
||
Also all crashes from the reports come from < 144.0 as Bug 1979106 is fixed in 144.0.
Comment 14•18 days ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #13)
Will ship downstream patch for it.
Sorry to bother you, do you have an ETA for backporting to 143? I have a system on which the browser is basically unusable because of this on 143. Thanks!
Updated•18 days ago
|
Comment 16•7 days ago
|
||
Reopening. Looks like Fedora crashes only. Bug 1990430 (GCC 15) may be related here.
Comment 18•7 days ago
|
||
We see first crashes on Aug 19.
Comment 19•7 days ago
|
||
It really looks related to this GCC update: https://bodhi.fedoraproject.org/updates/FEDORA-2025-483b46505e
https://koji.fedoraproject.org/koji/buildinfo?buildID=2787285
Built on Aug 09.
Updated•7 days ago
|
Updated•5 days ago
|
Description
•