Closed Bug 1402361 Opened 7 years ago Closed 7 years ago

Stack overflow on https://crapeyewear.returnly.com/

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
57 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla58
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 --- unaffected
firefox57 --- fixed
firefox58 --- fixed

People

(Reporter: bc, Unassigned)

References

(
URL
)

Details

(Keywords: crash, regression)

Attachments

(1 file)

Assertion failure: set_.empty() stack
2.92 KB, text/plain
Details
1. https://crapeyewear.returnly.com/ 2. Crash Beta/57, Nightly/58 but not Release/56 On Windows this crashes with EXCEPTION_STACK_OVERFLOW with a variety of stacks and fatal assertions. The variety is probably due to the stack overflow happening at different places, but I could be wrong. On my local Fedora it crashes immediately and I don't see any indication as to why in the output log nor can I get today's nightly to submit a crash report. I'm not providing stacks or logs since there are so many and each are probably unrelated to the real issue here. s-s just in case until someone who knows how to debug this has a look.
minor correction for Release/56: I did see a shutdown fatal assertion but have not so far been able to reproduce: ERROR: GC found 4 live Cells at shutdown Assertion failure: set_.empty(), at /mozilla/builds/release/mozilla/js/src/vm/RegExpShared.h:270
Saw this crash in a Mac 57 Nightly: bp-d2dea0eb-b835-4da9-987b-16d8a0170925. Only one function in the stack so I guess that got corrupted--not a good sign.
Don't seem to crash on a 58 nightly.
Group: core-security → core-security-release
I wasn't able to reproduce with either Beta/57 nor Nightly/58 on my locally built Fedora from this morning nor with a downloaded Nightly/58 opt build.
Regression Range: INFO: Last good revision: 5fb440d47ab9ebfa9633ff88274f221924f3cc3a INFO: First bad revision: 13f651129c38f79e0b7efa67892dcb296e41fe1a INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5fb440d47ab9ebfa9633ff88274f221924f3cc3a&tochange=13f651129c38f79e0b7efa67892dcb296e41fe1a Fix range: INFO: First good revision: d26a0adf4c2e501b6eeea2e77f26a4265643c238 INFO: Last bad revision: ac2290900129461001942117da9fd0019e214ac7 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ac2290900129461001942117da9fd0019e214ac7&tochange=d26a0adf4c2e501b6eeea2e77f26a4265643c238 So if I were a betting man, I'd say this was a regression from bug 1400599 that was fixed by bug 1401840. Which is already uplifted to Beta for 57b3, which was released today. So I think we can open this bug up and call it a day.
Blocks: 1400599
Status: NEW → RESOLVED
Has Regression Range: --- → yes
Closed: 7 years ago
status-firefox55: --- → unaffected
status-firefox57: affected → fixed
status-firefox58: affected → fixed
status-firefox-esr52: --- → unaffected
Component: General → DOM
Depends on: 1401840
Keywords: regressionwindow-wanted
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
If you were a betting man, you would win, because bug 1401840 did in fact fix a stack overflow crash that resulted from the fix for bug 1400599. ;) Looking at the https://crapeyewear.returnly.com/ site we have: 1) <html> has visible overflow. 2) <body> has hidden overflow, so propagates it to the viewport, given #1. 3) <html> and <body> are both display:inline, so inserting blocks in them will reframe the <html>, and removing the <body> will likewise reframe the <html> and now you have the conditions of the recursion from bug 1401840. This was a safe stack overflow (just running out of stack, no invalid accesses), so not security-sensitive.
Group: core-security-release
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: