Closed Bug 1489957 Opened 6 years ago Closed 6 years ago

Crash in VirtualAlloc

Categories

(Core :: General, defect)

Unspecified
Windows 7
defect
Not set
critical

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?
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)
See Also: → 1490042
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?
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)
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)
Anthony - is this the kind of thing a LLT engineer should have a look at?
Flags: needinfo?(ajones)
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.)
(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)
(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)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
Flags: needinfo?(ajones)
Flags: needinfo?(mstange.moz)
You need to log in before you can comment on or make changes to this bug.