Closed Bug 1011077 Opened 9 years ago Closed 9 years ago

crash in NS_NewRunnableMethod<nsServerSocket*, void ( nsServerSocket::*)(void)>(nsServerSocket*, void ( nsServerSocket::*)(void))


(Core :: Layout, defect)

32 Branch
Windows NT
Not set



Tracking Status
firefox32 - affected


(Reporter: jbecerra, Unassigned)


(Keywords: crash, topcrash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-69376350-7f7c-4055-b016-4b48d2140509.

Filing under netwerk because I couldn't find similar entries for NS_NewRunnableMethod.

This is a top crasher on nightly, and it started to appear on 5/5. All of these crashers are on amd64. There's one user comment only, and it says the browser crashed when opening a new tab. Most are on Windows 7 and Windows 8.1 (but not Windows 8).

0 	xul.dll 	NS_NewRunnableMethod<nsServerSocket *,void ( nsServerSocket::*)(void)>(nsServerSocket *,void ( nsServerSocket::*)(void)) 	
1 	xul.dll 	NS_NewRunnableMethod<nsServerSocket *,void ( nsServerSocket::*)(void)>(nsServerSocket *,void ( nsServerSocket::*)(void)) 	
2 	xul.dll 	PL_DHashTableFinish(PLDHashTable *) 	
3 	xul.dll 	PL_DHashTableFinish(PLDHashTable *) 	
4 	xul.dll 	NS_NewRunnableMethod<nsServerSocket *,void ( nsServerSocket::*)(void)>(nsServerSocket *,void ( nsServerSocket::*)(void)) 	
5 	xul.dll 	nsCSSFontFaceStyleDecl::RemoveProperty(nsAString_internal const &,nsAString_internal &) 	
6 	xul.dll 	NS_NewRunnableMethod<nsServerSocket *,void ( nsServerSocket::*)(void)>(nsServerSocket *,void ( nsServerSocket::*)(void)) 	
7 	xul.dll 	nsCSSFontFaceStyleDecl::RemoveProperty(nsAString_internal const &,nsAString_internal &) 	
8 	xul.dll 	nsStyleImage::IsOpaque() 	
9 	mozglue.dll 	arena_malloc_small 	memory/mozjemalloc/jemalloc.c
10 	mozglue.dll 	arena_malloc 	memory/mozjemalloc/jemalloc.c
11 	xul.dll 	NS_NewStyleContext(nsStyleContext *,nsIAtom *,nsCSSPseudoElements::Type,nsRuleNode *,bool) 	
12 	xul.dll 	mozilla::ElementRestyler::InitializeAccessibilityNotifications() 	
13 	xul.dll 	PresShell::RenderSelection(nsISelection *,nsIntPoint &,nsIntRect *) 	
14 	xul.dll 	nsCSSFrameConstructor::ConstructRootFrame() 	
15 	xul.dll 	nsCSSFrameConstructor::WrapFramesInFirstLetterFrame(nsIContent *,nsIFrame *,nsFrameItems &) 	
16 	xul.dll 	mozilla::dom::DocumentFragment::WrapNode(JSContext *) 	
17 	xul.dll 	mozilla::FrameLayerBuilder::AddThebesDisplayItem(mozilla::ThebesLayerData *,nsDisplayItem *,mozilla::DisplayItemClip const &,nsIFrame *,mozilla::LayerState,nsPoint const &,nsAutoPtr<nsDisplayItemGeometry>)

More reports can be found here:
I'm going to guess this is a corrupted hash table in nsCSSFontFaceStyleDecl::RemoveProperty.. the class doesn't appear to use server sockets (and I would hope not! :))

the crash-stats link actually only shows one particular build id with server sockets on the stack, but there are other entries for the more generic nsCSSFontFaceStyleDecl signature.. suggesting it was just bad linking luck that day that server sockets matched the corruption.
Component: Networking → CSS Parsing and Computation
The whole stack doesn't make sense, actually; I think it's just a corrupted stack. Most of the purported callers don't actually call the method that the stack shows them calling.

 - arena_malloc_small shouldn't have any calls to nsStyleImage::IsOpaque()
 - nsStyleImage::IsOpaque() doesn't have any calls to nsCSSFontFaceStyleDecl::RemoveProperty()
 - PresShell::RenderSelection() doesn't have any calls to InitializeAccessibilityNotifications
 - mozilla::dom::DocumentFragment::WrapNode() doesn't have any calls to nsCSSFrameConstructor::WrapFramesInFirstLetterFrame
Component: CSS Parsing and Computation → General
The other stacks (linked from the "reports" tab at the link at the end of comment 0) do all seem to have some common threads, though, from clicking through a few of them.
 - The highest stack frame shown is generally nsCSSFrameConstructor::WrapFramesInFirstLetterFrame. (not sure why we don't have any caller information for that function)
 - nsCSSFrameConstructor::ConstructRootFrame() and nsStyleImage::IsOpaque() and NS_NewStyleContext are generally in the stack somewhere.

So, while the stack is bogus, it looks like it's probably some variety of layout-flavor.
Component: General → Layout
Crash-stats had some bad symbols for nightly last week. I opened several of these minidumps in a debugger and they're all RuleHash_ClassTable_GetKey.
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.