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

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?

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.

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

[email protected], 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?

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

[email protected], 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.

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

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.

(I assume Julien wanted to ni? Luca, moving back to 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?

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

2. 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:

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

4. 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!

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

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

The easiest way I can think of is to create a full copy of the profile directory in a new path and then start Firefox on that new copy of the profile dir and then run a Firefox instance on that specific profile from the command line with the "-Profile" cli option, e.g. something like the following:

cp -rf ~/.mozilla/firefox/YOUR-ORIGINAL-PROFILEDIR /tmp/NEW-PROFILE-COPY

firefox -no-remote -Profile /tmp/NEW-PROFILE-COPY

You can determine the path to your current original profile dir by looking to the one included in the about:support details, after starting the new Firefox instance on the new copy also confirm from about:support that the instance is running on the profile copy directory as expected.

As a side note, if the profile is connected to a Firefox account, then you may want to disconnect it from Firefox account before applying any change that would be synced to the other Firefox instances (e.g. by navigating a tab to about:preferences#sync) to avoid the changes applied to the profile copy to test out this issue to be synced into the other Firefox instances.

Hi Julien,
do you have any other thoughts about what kind of details we may want to gather to get a better understanding about this issue and how it should be fixed?

As I mentioned in comment 17, this issue doesn't feel actionable on the WebExtensions side with the details collected so far, e.g. it is still unclear how what the installed extensions are doing is contributing to what leads to the crash hit by the SamplerThread thread.

Would the "preventing a crash to be hit on the SamplerThread thead" part of this issue be actionable from a GeckoProfiler perspective with the details we got so far from the crash reports and the comments in this issue?

Looking at some crashes from comment 5; I see this is crashing in the JS engine, but not always at the same location. see these direct links:

https://crash-stats.mozilla.org/report/index/7d2505a0-2c7f-47ec-96f1-a498b0241208
https://crash-stats.mozilla.org/report/index/f7aed262-6857-477e-bab6-f73d30241208
https://crash-stats.mozilla.org/report/index/22b39a40-44e9-43cb-a5c0-60f750241208
https://crash-stats.mozilla.org/report/index/5d3eef02-9b63-4048-bbb6-92fbb0241211
https://crash-stats.mozilla.org/report/index/cc4012bd-238c-40c9-83c7-8e99e0241211
https://crash-stats.mozilla.org/report/index/ba26494d-42ab-4835-b625-5647f0241211
https://crash-stats.mozilla.org/report/index/472a2d9a-9500-498b-8714-430a80241211
https://crash-stats.mozilla.org/report/index/a1937c3f-1663-4fec-b824-6a2d60241211
https://crash-stats.mozilla.org/report/index/eb5e1c21-3c35-4da6-a5d2-38b830241211
https://crash-stats.mozilla.org/report/index/71684621-f53a-4025-a515-0085d0241211
https://crash-stats.mozilla.org/report/index/0baeff05-4e6b-40af-bc7c-0aaec0241211

Hey Jan, is there anything that makes sense to you with these crashes?

It's good to note that this is Fedora's Firefox, and not Mozilla's build of Firefox. Mr. Beedell by chance, would you be able to try your same steps with an official build from Mozilla?

NI Jandem for previous comment

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #20)

Hi Julien,
do you have any other thoughts about what kind of details we may want to gather to get a better understanding about this issue and how it should be fixed?

As I mentioned in comment 17, this issue doesn't feel actionable on the WebExtensions side with the details collected so far, e.g. it is still unclear how what the installed extensions are doing is contributing to what leads to the crash hit by the SamplerThread thread.

Would the "preventing a crash to be hit on the SamplerThread thead" part of this issue be actionable from a GeckoProfiler perspective with the details we got so far from the crash reports and the comments in this issue?

Thanks for looking at it Luca!

1. #c19

   As a side note, if the profile is connected to a Firefox account, then you may want to disconnect it from Firefox account before applying any change that would be synced to the other Firefox instances (e.g. by navigating a tab to about:preferences#sync) to avoid the changes applied to the profile copy to test out this issue to be synced into the other Firefox instances.

   I've disabled it, per firefox about:preferences?entrypoint=fxa_app_menu#sync:~:text=Syncing:%20OFF:

   Syncing: OFF
   

   Thanks. To ensure that it doesn't impact the test, the slowdown reproduces regardless (that is, with TM5K active but synchronisation disabled, and it reproduces within 5s).

2. #c21

   It's good to note that this is Fedora's Firefox, and not Mozilla's build of Firefox. Mr. Beedell by chance, would you be able to try your same steps with an official build from Mozilla?

   I've ensured that it immediately reproduces in firefox-135.0.1-1.fc41.x86_64. However, mozilla.org/en-GB/firefox/download/thanks doesn't offer 135.0.1, and I don't want to download it from an unofficial source. Consequently, I downloaded the 136.0 that it offered, and duplicated the relevant profile into it.

3. #c19

   cp -rf /home/RokeJulianLockhart/.mozilla/firefox/iauorfww.snrxu8 /tmp/iauorfww.snrxu82
   firefox -no-remote -Profile /tmp/NEW-PROFILE-COPY
   

   Using about:profiles to ascertain the default, I performed the undermentioned (where $HOME = '/home/RokeJulianLockhart'):

   #!/usr/bin/env pwsh
   $ProfileName = 'iauorfww.snrxu8'
   $NewPath = "/tmp/$ProfileName"
   cp -rf "$HOME/.mozilla/firefox/$ProfileName" $NewPath && `
   	& '/home/RokeJulianLockhart/Downloads/firefox/firefox' --no-remote --profile $NewPath
   

   I modified the flags to be the GNU style because man firefox, with | greps of no-remote and profile, returned solely --no-remote and --profile path, respectively. I realise that man refers to firefox-135.0.1-1.fc41.x86_64, but I presumed it'd work for V136 too.

4. I took a profile loading the heaviest tab that I know of: wim.nl.tab.digital/apps/tasks/collections/all, per github.com/nextcloud/tasks/issues/2417. The profile is available at share.firefox.dev/43m5mgv.

   This reproduced the issue, but as does merely switching between enough tabs. It's most noticeable when simultaneously loading multiple new ones, especially heavier ones.

5. After using the duplicated profile's original state as a control (as aforementioned), I then disabled each extension (excepting TM5K) individually, until solely TM5K remained. The issue remained. I've published a profile (that hopefully confirms this) at share.firefox.dev/4i2As0R.

Consequently, it reproduces with solely that extension activated, in official binaries. Less so, certainly, but enough that my the new OOM killer for my DE, KDE Plasma 6, had to kick in 4 times during the course of this testing, and once even with solely TM5K activated. I've attached a screenshot to demonstrate (Warp is my terminal, hosting the shell that the FF binary was invoked via).

Is this adequate confirmation...? 😬

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

Is this adequate confirmation...? 😬

Thank you so much!

I took an initial look to the two profiles linked from comment 24 (share.firefox.dev/43m5mgv and share.firefox.dev/4i2As0R) and it looks like TM5K is triggering quite same time spent on IndexedDB and StructureClone blobs related to browser.storage.local onChanged events being serialized and deserialized.

Based on a look I took into what in TM5K may be triggering that much activity around IndexedDB and StructureClone blobs serialization/deserialization I noticed that TM5K may be storing the entire sessions informations (which I guess it may include some state captured for each tab and windows opened) into a single sessions key stored in the browser.storage.local storage area and TM5K background page has a browser.storage.local.onChanged listener that seems to be setting the entire new sessions value received again into the same storage area here: https://github.com/jaszhix/tab-master-5000-extension/blob/e4e9aa9a228f4a2093dbcb5107e3dc80bef02369/app/scripts/bg/bg.ts#L247

I haven't yet double-checked but I suspect that may be triggering again both the IndexedDB activity to store again the same data (which was already stored in the local area given that it got notified through onChanged event) and that to trigger again an onChanged API event call, which may then contribute (especially with a certain amount of tabs and windows to grow the size of the sessions value) to be slowing down both the child WebExtensions process that the parent process (which is involved due to the onChanged event).

Thanks for the information!

I don't understand if you still see the same crash while profiling with the official binaries though?

#c26

:julienw, I haven't been able to reproduce that crash since, presumably because the problem intensifies during prolonged usage, and I no longer keep TM5K enabled due to how nigh unusable it renders my profile. It was somewhat exceptional regardless, though.

I suggest that this issue's title be re-scoped to reflect the content of the discussion since it was filed. However, unlike you developers, who can comprehend the profiles I provide, they're fairly incomprehensible to me, so I do not know what to apply as the new title.

(In reply to Julien Wajsberg [:julienw] from comment #21)

Hey Jan, is there anything that makes sense to you with these crashes?

It's good to note that this is Fedora's Firefox, and not Mozilla's build of Firefox.

It's hard to say. It's possible that Fedora's Firefox builds are confusing the profiler code somehow, or it's a bug in the JS engine's profiling code but to make progress on that we'd need to be able to reproduce this.

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

#c26

:julienw, I haven't been able to reproduce that crash since, presumably because the problem intensifies during prolonged usage, and I no longer keep TM5K enabled due to how nigh unusable it renders my profile. It was somewhat exceptional regardless, though.

The crash info really shows something different than a memory leak (not a OOM), they are showing a null pointer dereferencing. So there might be 2 different issues. It would be good to focus on just one in this bug, otherwise it's too confusing.

This bug was ultimately filed because I'd been experiencing such prolonged and significant slowdowns, and finally had something to show for it, when the browser finally crashed.

If you're correct that the crash was actually unrelated, considering the thread history for this bug being primarily about what I'd misattributed to the cause, rather than the cause, should I create a new bug about what TM5K does the browser (if it's even worth reporting here, rather than merely at its own tracker) or should this issue be repurposed, and another filed about the crash?

In a Discourse thread, comments can be moved from one thread to another. Does Bugzilla support this? Perhaps that'd be worth suggesting, if not.

I'd file a new bug for the crash, thanks again.

Luca explained in comment 25 that the extension repeatedly triggers storage.onChanged. While we could try to optimize its implementation (bug 1842042), it is ultimately an issue with the extension, because it basically triggers some infinite loop that saturates the memory.

This report should be forwarded to the extension developer, who is the only one that can fix this issue. An issue was already filed before at https://github.com/jaszhix/tab-master-5000-extension/issues/33

(In reply to Julien Wajsberg [:julienw] (PTO -> Mar 17) from comment #31)

I'd file a new bug for the crash, thanks again.

If someone filed the bug report for the profiler crash, please link it here for visibility.

If someone filed the bug report for the profiler crash, please link it here for visibility.

I don't think anyone has. I'll gladly do that, but I don't know what crash report correlates to the crash, since I've shared about 12. Do you?

From my limited investigation, all of them seemed to link to the same crash.

The common parts of the stack traces are as follows (from lower in the stack to higher in the stack):

• DoSharedSample(bool, unsigned int, mozilla::profiler::ThreadRegistrationUnlockedReaderAndAtomicRWOnThread const&, JS::ProfilingFrameIterator::Frame*, Registers const&, unsigned long, unsigned long, ProfileBuffer&, mozilla::StackCaptureOptions)
  • ExtractJsFrames(bool, mozilla::profiler::ThreadRegistrationUnlockedReaderAndAtomicRWOnThread const&, Registers const&, ProfilerStackCollector&, JS::ProfilingFrameIterator::Frame*, StackWalkControl*) - called from DoSharedSample at https://searchfox.org/mozilla-central/rev/a8a00d67c6c7118f0b95cffa26740202c3b9e6f3/tools/profiler/core/platform.cpp#2976-2977
    • JS::ProfilingFrameIterator::ProfilingFrameIterator(JSContext*, JS::ProfilingFrameIterator::RegisterState const&, mozilla::Maybe<unsigned long> const&)
      • JS::ProfilingFrameIterator::iteratorConstruct(JS::ProfilingFrameIterator::RegisterState const&)
        • js::jit::JSJitProfilingFrameIterator::JSJitProfilingFrameIterator(JSContext*, void*, void*) (most common)
          • js::jit::JSJitProfilingFrameIterator::tryInitWithPC(void*) - and then more, callees of https://searchfox.org/mozilla-central/rev/a8a00d67c6c7118f0b95cffa26740202c3b9e6f3/js/src/jit/JSJitFrameIter.cpp#586-606
        • js::wasm::ProfilingFrameIterator::ProfilingFrameIterator(js::jit::JitActivation const&, JS::ProfilingFrameIterator::RegisterState const&)
          • js::wasm::ProfilingFrameIterator::initFromExitFP(js::wasm::Frame const*)

Based on this, I recommend filing a bug in Core::Gecko Profiler or Core::JavaScript Engine::JIT

#c35

I've filed id=1955781. It's probably the best I can do.