Closed
Bug 1489957
Opened 6 years ago
Closed 6 years ago
Crash in VirtualAlloc
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: gsvelto, Unassigned)
References
Details
(Keywords: crash)
Crash Data
This bug was filed from the Socorro interface and is report bp-0044b55a-8759-47e7-956d-b06800180909. ============================================================= Top 10 frames of crashing thread: 0 kernelbase.dll VirtualAlloc 1 emet64.dll emet64.dll@0x47fd9 2 emet64.dll emet64.dll@0x867b9 3 emet64.dll emet64.dll@0x420c4 4 emet64.dll emet64.dll@0x85218 5 xul.dll exp2 6 emet64.dll emet64.dll@0x86678 7 xul.dll PrintfAppend<char>::append xpcom/string/nsTSubstring.cpp:1131 8 mozglue.dll mozilla::PrintfTarget::vprint mozglue/misc/Printf.cpp:881 9 @0xfff ============================================================= I found a handful of this crashes, all with this stack showing a string being appended too and resulting in a stack overflow. Note how some frames from the enhanced mitigation experience toolkit (EMET) are present on the stack. I don't know how it works, does it inject itself to detect stack overflows?
Comment 1•6 years ago
|
||
A lot of these seem to be happening inside the profiler. ProfilingStack::ensureCapacitySlow(). I'm not sure how the ctor for ProfilingStackFrame ends up doing a printf. Presumably it is printing a large string which is using stack space for some intermediate buffer and it ends up blowing out the stack? I think there was some work done recently to reduce the stack size for threads, so maybe that's why they're running out of stack space. Markus, could you take a look? Maybe something can be done. There's also a second cluster of crashes that look like a legit infinite recursion inside type inference GC: bp-0d7f8823-78fd-4247-9a39-5fc420180908 bp-316db272-008e-41c2-a87f-019280180907 I'll file a separate bug for that and mark it as see-also to this bug.
Flags: needinfo?(mstange)
Comment 2•6 years ago
|
||
Markus pointed me to this bug, but I cannot make sense of those stacks, they're happening inside malloc. From IRC: 18:41 <emilio> mstange: the only stack that would make sense is operator new(.., fallible_t) -> base_alloc -> pages_commit -> VirtualAlloc, I think 18:42 <emilio> mstange: is there any chance the stack would be that, and the kernel is somehow killing us?
Reporter | ||
Comment 3•6 years ago
|
||
The part inside malloc() is probably caused by EMET kicking in, specifically it's structured exception handler overwrite protection (SEHOP) which is supposed to prevent exploitation of stack overflows. What is almost certain is that we're overflowing a stack, the bottom of it though gets murkier because of EMET. NI'ing Carl who knows a lot more about Windows internals than I do.
Flags: needinfo?(ccorcoran)
Comment 4•6 years ago
|
||
I don't think I have much to add unfortunately; I don't know much about EMET. My instinct agrees with Gabriele that the emet64.dll stack frames are a red herring here; the real issue is occurring before EMET kicks in.
Flags: needinfo?(ccorcoran)
Comment 5•6 years ago
|
||
Anthony - is this the kind of thing a LLT engineer should have a look at?
Flags: needinfo?(ajones)
Comment 6•6 years ago
|
||
This is a pretty generic signature that could likely be added to the prefix list or the skip list. Looking at recent crashes, 20 out of the 22 are bug 1490042, which has been fixed on Nightly, so I'm not sure it is worth keeping this bug open. (I don't see any more of the profiler looking crashes from comment 0.)
Comment 7•6 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #6) > This is a pretty generic signature that could likely be added to the prefix > list or the skip list. Looking at recent crashes, 20 out of the 22 are bug > 1490042, which has been fixed on Nightly, so I'm not sure it is worth > keeping this bug open. (I don't see any more of the profiler looking crashes > from comment 0.) Gabriele - do you agree with Andrew's analysis? Can we close this bug?
Flags: needinfo?(gsvelto)
Reporter | ||
Comment 8•6 years ago
|
||
(In reply to Selena Deckelmann :selenamarie :selena use ni? pronoun: she from comment #7) > Gabriele - do you agree with Andrew's analysis? Can we close this bug? Yes, the original stack doesn't show up anymore in recent reports.
Flags: needinfo?(gsvelto)
Updated•6 years ago
|
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
Updated•6 years ago
|
Flags: needinfo?(ajones)
Updated•1 year ago
|
Flags: needinfo?(mstange.moz)
You need to log in
before you can comment on or make changes to this bug.
Description
•