Closed Bug 1752697 Opened 3 years ago Closed 2 years ago

Crash in [@ set_alt_signal_stack_and_start]

Categories

(Toolkit :: Crash Reporting, defect, P3)

Product:
Toolkit
Component:
Crash Reporting
Version:
Firefox 98
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox-esr91 --- unaffected
firefox96 --- unaffected
firefox97 --- unaffected
firefox98 --- fix-optional

People

(Reporter: calixte, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: crash, regression)

Crash Data

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/241f8143-1473-4d08-9b91-0a93b0220129

Reason: SIGSEGV / SI_KERNEL

Top 10 frames of crashing thread:

0 None @0x00007ff9f22bcffe 
1 None @0x00007ff9f22bd0c8 
2 None @0x00007ff9f22bd140 
3 None @0x00007ff9f22bc728 
4 None @0x00007ff9f22bba2e 
5 None @0x00007ff9f22bb33d 
6 None @0x00007ff9f22b7e08 
7 None @0x00007ff9f22b7bdd 
8 None @0x00007ff9f22bdcbe 
9 None @0x00007ff9f5244db1

There is 1 crash in nightly 98 with buildid 20220128190550. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1678152.

[1] https://hg.mozilla.org/mozilla-central/rev?node=cf94448b84dc

Flags: needinfo?(gsvelto)

The signature is misleading. The top frames are all empty because libxul was unloaded so the first entry in the crash signature is set_alt_signal_stack_and_start() but that doesn't have anything to do with the crash, it's there just because it's the first actual symbol that gets picked up. I'll leave this open to see if something else crops up but I don't think this will be actionable.

Flags: needinfo?(gsvelto)
Has Regression Range: --- → yes
Severity: S2 → S4
Priority: -- → P3
No longer blocks: 1678152

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.