Open Bug 1935897 Opened 3 months ago Updated 10 days ago

Tab or Firefox crashes during performance profile capture.

Categories

(WebExtensions :: Untriaged, defect)

Product:
WebExtensions
Component:
Untriaged
Version:
Firefox 133
Platform:
x86_64
Linux
Type:
defect

Tracking

(Not tracked)

People

(Reporter: zn7esutb, Unassigned)

References

Details

Attachments

(1 file)

Reproduction screencast (for `#c0`).
1.94 MB, video/mp4
Details

Steps to reproduce

  1. Install Fedora-KDE-Live-x86_64-41-1.4.iso:

    Version

    1. #!/usr/bin/env -S bash
kinfo

    2. #!/usr/bin/env -S xdg-open
Operating System       : Fedora Linux 41
KDE Plasma Version     : 6.2.4
KDE Frameworks Version : 6.8.0
Qt Version             : 6.8.0
Kernel Version         : 6.11.10-300.fc41.x86_64 (64-bit)
Graphics Platform      : Wayland
Processors             : 12 × AMD Ryzen 5 7600X 6-Core Processor
Memory                 : 30.4 GiB of RAM
Graphics Processor     : AMD Radeon RX 5700

  2. Install firefox-133.0-2.fc41.x86_64.rpm:

    Version

    1. #!/usr/bin/env -S bash
dnf info 'firefox'

    2. #!/usr/bin/env -S xdg-open
Name            : firefox
Epoch           : 0
Version         : 133.0
Release         : 2.fc41
Architecture    : x86_64
Installed size  : 228.3 MiB
Source          : firefox-133.0-2.fc41.src.rpm
From repository : @stored_transaction
Vendor          : Fedora Project

  3. Enable about:profiling with the default configuration.

  4. Create a new tab.

  5. Invoke the profiler.

  6. Visit a URI via the omnibox.

Actual results

Usually, the tab crashes, either immediately, or < 15s after visiting the URI. However, once, Firefox crashed, per bugzilla.redhat.com/show_bug.cgi?id=2331030#c0.

Expected results

I should be able to capture a performance profile.

#c0

Captured Profiles (uploaded to share.firefox.dev):

  1. 4itBvIa
  2. 3VvkEum
  3. 41jdWvn
Component: Untriaged → Performance Tools (Profiler/Timeline)
Product: Firefox → DevTools

Looking at one profile, after the crash webextensions seem to suddenly consume a lot of memory. But no idea what could lead to the crash.
Julien can you take a look at this?

Flags: needinfo?(felash)

Can you please share the links to the crash reports from about:crashes? I hope that Fedora RPM Firefox version uploads them and we have proper symbols for them.

Flags: needinfo?(felash) → needinfo?(zn7esutb)

From the redhat bug, here is the stack trace:

Truncated backtrace:
Thread no. 1 (7 frames)
 #0 js::ScriptWarmUpData::isJitScript at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/vm/JSScript.h:1251
 #1 js::BaseScript::hasJitScript at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/vm/JSScript.h:1585
 #2 js::BaseScript::hasIonScript at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/vm/JSScript-inl.h:164
 #3 js::jit::JSJitProfilingFrameIterator::tryInitWithPC at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/jit/JSJitFrameIter.cpp:590
 #4 js::jit::JSJitProfilingFrameIterator::JSJitProfilingFrameIterator at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/jit/JSJitFrameIter.cpp:532
 #5 JS::ProfilingFrameIterator::iteratorConstruct at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/vm/Stack.cpp:571
 #6 JS::ProfilingFrameIterator::ProfilingFrameIterator at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/vm/Stack.cpp:489

Dear reporter, can you please also share whether this was working for you before and now it doesn't anymore, or is it the first time you tried using the profiling capabilities?

#c4

felash@gmail.com, it's nice to be called dear. I could get used to that!

This is the first time I've tried to use the profiling capabilities on this OS (and, thus, Firefox) installation. It worked on a previous Fedora 40 installation, on the same hardware, approximately 7 months ago.

#c3

All have been submitted:

Report ID Date Submitted
bp-7d2505a0-2c7f-47ec-96f1-a498b0241208 08/12/2024, 17:04
bp-f7aed262-6857-477e-bab6-f73d30241208 08/12/2024, 16:07
bp-c0d911f7-788d-4602-9e62-66c460241208 08/12/2024, 16:07
bp-22b39a40-44e9-43cb-a5c0-60f750241208 08/12/2024, 16:00
bp-5d3eef02-9b63-4048-bbb6-92fbb0241211 11/12/2024, 15:00
bp-cc4012bd-238c-40c9-83c7-8e99e0241211 11/12/2024, 15:00
bp-ba26494d-42ab-4835-b625-5647f0241211 11/12/2024, 15:00
bp-472a2d9a-9500-498b-8714-430a80241211 11/12/2024, 15:00
bp-a1937c3f-1663-4fec-b824-6a2d60241211 11/12/2024, 15:00
bp-eb5e1c21-3c35-4da6-a5d2-38b830241211 11/12/2024, 15:00
bp-71684621-f53a-4025-a515-0085d0241211 11/12/2024, 15:00
bp-0baeff05-4e6b-40af-bc7c-0aaec0241211 11/12/2024, 15:00

It's rather frustrating that they aren't automatically (at least, by default) - can that be enabled?

Flags: needinfo?(zn7esutb)

Looking at one profile, after the crash webextensions seem to suddenly consume a lot of memory. ⁽¹⁾

jdescottes@mozilla.com, my FF installation is stuttery. I'd say that there's some kind of memory leak in one of the WEs, but it's like from the point of initialisation. I'll try capturing a profile switching between tabs, since that's when it's most obvious.

#c6

I couldn't - it crashed too. See bp-69475cdf-a559-4a18-be99-0378a0241211.

#c0

firefox --safe-mode appears to entirely resolve this. I'm going to go down my list of about:addons one-by-one to ascertain which the culprit is. I'll leave this issue open because add-ons from addons.mozilla.org shouldn't be able to cause this.

#c7

I have managed to upload a genuinely useful performance profile at share.firefox.dev/4gKUT1l by profiling about:processes#:~:text=Extensions for 5s.

If not included in the profiles, I've also manually observed that switching tabs causes the extensions section to consume "100%" (although, obviously, not literally 100%) of the CPU.

#c9

I've ascertained which extension is the culprit. It's tab_master_5000-2.9.7.xpi (from addons.mozilla.org). I've reported this to its developer(s) at github.com/jaszhix/tab-master-5000-extension/issues/33#issue-2754105909.

I'll leave this issue open because add-ons from addons.mozilla.org shouldn't be able to cause this.

Is this actionable from Mozilla's end? Specifically, should a misbehaving add-on be temporarily redacted from the marketplace, and/or can any code modifications to Firefox be included to mitigate the effect of whatever the performance profile demonstrates the add-on is erroneously doing?

I ask because, for the purpose of running a browser, this is a powerful machine, as #c0 explains. it shouldn't be slowed by whatever is going so seriously wrong in that extension.

Flags: needinfo?(felash)
See Also: → 1756368

Hey Luca, I believe this is a question for you. (see comment 10).

Component: Performance Tools (Profiler/Timeline) → Untriaged
Flags: needinfo?(felash)
Product: DevTools → WebExtensions

The Bugbug bot thinks this bug should belong to the 'DevTools::General' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → General
Product: WebExtensions → DevTools

(I assume Julien wanted to ni? Luca, moving back to WebExtensions)

Component: General → Untriaged
Flags: needinfo?(lgreco)
Product: DevTools → WebExtensions

#a4397835_691781

Apologies for the separate notifications for those. It was because I couldn't add a URI with a text fragment directive (like https://bugzilla.redhat.com/show_bug.cgi?id=2331030#c0:~:text=2024%2D12%2D08%2016:03:04%20UTC-,Description%20of%20problem:,-I%20tried%20to) to the "See also" section. I've reported this at show_bug.cgi?id=1944318.

(In reply to Mr. Beedell, Roke Julian Lockhart from comment #10)

#c9

I've ascertained which extension is the culprit. It's tab_master_5000-2.9.7.xpi (from addons.mozilla.org). I've reported this to its developer(s) at github.com/jaszhix/tab-master-5000-extension/issues/33#issue-2754105909.

About the extension that is mentioned as the one triggering the issue:

  • Are you able to hit a crash with just that extension installed?
  • Can you hit a crash with only that extension installed also in a new empty profile or only in the existing profile where that extension for being used for a longer time?

If you can't hit a crash:

  • is a visible performance impact being hit with only that extension installed? would you be able to collect a profile while hitting that performance impact?
Flags: needinfo?(lgreco) → needinfo?(zn7esutb)

(In reply to Mr. Beedell, Roke Julian Lockhart from comment #10)

I'll leave this issue open because add-ons from addons.mozilla.org shouldn't be able to cause this.

Is this actionable from Mozilla's end? Specifically, should a misbehaving add-on be temporarily redacted from the marketplace, and/or can any code modifications to Firefox be included to mitigate the effect of whatever the performance profile demonstrates the add-on is erroneously doing?

I ask because, for the purpose of running a browser, this is a powerful machine, as #c0 explains. it shouldn't be slowed by whatever is going so seriously wrong in that extension.

I'll leave this issue open because add-ons from addons.mozilla.org shouldn't be able to cause this.

Is this actionable from Mozilla's end? Specifically, should a misbehaving add-on be temporarily redacted from the marketplace, and/or can any code modifications to Firefox be included to mitigate the effect of whatever the performance profile demonstrates the add-on is erroneously doing?

I ask because, for the purpose of running a browser, this is a powerful machine, as #c0 explains. it shouldn't be slowed by whatever is going so seriously wrong in that extension.

We don't usually unlist entire add-ons from addons.mozilla.org, unless there are actually malicious (also this addon doesn't look like a recommended one, the recommended set of addons is one for which we have more direct contacts with the related extension developers).

In this particular case, it doesn't seem it is yet clear how that particular extension leads to a crash, and the comments seems to suggest that a crash is only being hit while profiling the Firefox instance (and so not something that all users with that extension installed would be hitting).

(In reply to Julian Descottes [:jdescottes] from comment #13)

(I assume Julien wanted to ni? Luca, moving back to WebExtensions)

Based on the few crash reports that I've been able to see from the crash-stats (I took a look to all the ones mentioned in comment 5), it looks like all crash reports submitted:

  • are hitting a crash in the SamplerThread (some on a content child process and others on the main parent process)
  • did happen with more than a few extensions installed along with the "Tab Master 5000" one.

I also took a look to the profiler data linked from comment 1, in this particular one https://profiler.firefox.com/public/x23fz3nss8bq84nxxce5j68p0a1t9apvwg6sb7r I see some activity in the extensions process that looks like initialization work, which I assume may have been due to the extension process being restarted after a crash, but I couldn't see anything that would directly point to what kind of contribution the extension "Tab Master 5000" may have in triggering the crash.

I tried to install "Tab Master 5000" in a new profile and see if I would be hitting any visible perf impact or a crash while profiling the Firefox instance, but I wasn't able to hit either so far.

Nonetheless I wouldn't also exclude that to ensure "Tab Master 5000" enters into the state that triggers a crash while profiling (and maybe also perf impact without the profiling part) may require a Firefox profile with a certain amount of type of session history and/or windows/tabs open, or particular configs to be set on the extension side (e.g. extensions feature that may be only active if the user opt-ins), and so to investigate that we may need to pin point what may be missing to get to a complete steps to reproduce that would consistently reproduce the issue.

I don't have enought context / knowledge about the profiler internals and the kind of work that the SamplerThread is handling, and but this issue may not be actually actionable on the WebExtensions side with the information currently available.

#c15

About the extension that is mentioned as the one triggering the issue:

  1. Are you able to hit a crash with just that extension installed?

:lgreco, I can't test that in my default profile without doing too many changes to it than I'm comfortable with, so IDK. That is, unless duplicating a profile is trivial? If so, I'm unaware.

  1. Can you hit a crash with only that extension installed also in a new empty profile or only in the existing profile where that extension for being used for a longer time?

In my default profile, the slowness becomes apparent within ≈40s. I am able to provide a screencast and/or profile of this, if desirable.

In a new profile, it doesn't appear to occur. Like you, I presume that it's an interaction between extensions, but I've little idea due to how much of my browser's functionality I utilize. All that I am quite confident of is that since I'd experienced this across OSes sporadically for a few years, always a little while after first use, it's probably a combination of synchronised data and whatever doesn't come with the synchronisation that makes it take a little while to get to this state.

If you can't hit a crash:

  1. Is a visible performance impact being hit with only that extension installed?

As aforementioned, I am unable to easily evaluate this in my default profile, but it doesn't appear to occur in a new one.

  1. Would you be able to collect a profile while hitting that performance impact?

Yes. I can capture an external flame graph, etcetera. As long I don't have to compile anything, I can probably provide what you want.

Thank you for the assistance!

Flags: needinfo?(zn7esutb)
Blocks: 1937425
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: