Closed Bug 1984368 Opened 2 months ago Closed 5 days ago

[Fedora] Crash in [@ WaylandBuffer::IsAttached()]

Categories

(Core :: Widget: Gtk, defect, P3)

Unspecified
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1990430
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

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.

[1] https://searchfox.org/firefox-main/rev/7c5a5b3d014c0837bceaf210e5434e851cca389d/widget/gtk/WaylandBuffer.cpp#94

Flags: needinfo?(stransky)
Severity: -- → S2

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.

Flags: needinfo?(stransky)
Priority: -- → P3

(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.

(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.

Flags: needinfo?(stransky)

Encountered that. What info is needed?

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.

Flags: needinfo?(stransky) → needinfo?(arcadiy)
Flags: needinfo?(stransky)

Running with logs. However the crashes are unpredictable and intermittent and it may take some time.

Attached file log-truncated.txt

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

These are last 9,000,000 lines of the log prior to the crash in zstd.

Flags: needinfo?(arcadiy)

Cool, Thanks, will look at it.

Summary: [Fedora] Crash in [@ <name omitted> | mozilla::detail::InvalidArrayIndex_CRASH | ElementAt] → [Fedora] Crash in [@ WaylandBuffer::IsAttached()]
Flags: needinfo?(stransky) → needinfo?(aryx.bugmail)
See Also: → 1979106
Flags: needinfo?(aryx.bugmail)

Also all crashes from the reports come from < 144.0 as Bug 1979106 is fixed in 144.0.

Will ship downstream patch for it.

(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!

Status: NEW → RESOLVED
Closed: 18 days ago
Duplicate of bug: 1979106
Resolution: --- → DUPLICATE

Reopening. Looks like Fedora crashes only. Bug 1990430 (GCC 15) may be related here.

Status: RESOLVED → REOPENED
No longer duplicate of bug: 1979106
Resolution: DUPLICATE → ---
Duplicate of this bug: 1992244

We see first crashes on Aug 19.

Flags: needinfo?(stransky)
Flags: needinfo?(stransky)
See Also: → 1990430
Status: REOPENED → RESOLVED
Closed: 18 days ago5 days ago
Duplicate of bug: 1990430
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: