Closed Bug 724413 Opened 13 years ago Closed 7 years ago

Startup crash @ je_free | PL_DHashFreeTable | ChangeTable

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Version:
9 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: m_hasan0007, Unassigned)

References

Details

(Keywords: crash, Whiteboard: startupcrash)

Crash Data

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20100101 Firefox/10.0
Build ID: 20120129021758

Steps to reproduce:

Installed v10 from 9.0.1


Actual results:

Firefox Crashed maybe 20 times since then and will not start. AND it magically changed my network connection settings, disabling/changing my DHCP


Expected results:

Started Firefox with v10
My Firefox didn't crashed, a user's crashed - https://support.mozilla.org/en-US/questions/916814
Crash Signature: [@ nsVoidArray::IndexOf(void*) ]
Keywords: crash
OS: Windows XP → Windows 7
The user reports he Downgraded to v9.0.1 and its working for now.
-> https://support.mozilla.org/en-US/questions/916814#answer-306272
Another Crash Report -> https://crash-stats.mozilla.com/report/index/cb8013be-f99b-4327-8f36-581412120202
Crash Signature: [@ nsVoidArray::IndexOf(void*) ] → [@ nsVoidArray::IndexOf(void*) ] [@ je_free | PL_DHashFreeTable ]
Summary: Crash [nsVoidArray::IndexOf(void*)] → Crash [nsVoidArray::IndexOf(void*)] [@ je_free | PL_DHashFreeTable ]
Crash Signature: [@ nsVoidArray::IndexOf(void*) ] [@ je_free | PL_DHashFreeTable ] → [@ nsVoidArray::IndexOf(void*) ], [@ je_free | PL_DHashFreeTable ]
Have you tried starting Firefox 10 in Safe Mode?
As i mentioned earlier, my system didn't crashed some other user's crashed. See Comments 1-4.
I just filed the bug since i didn't found a relevant bug report based on the signature of the Crash Reports.
(In reply to mha007 from comment #6)
> As i mentioned earlier, my system didn't crashed some other user's crashed.
> See Comments 1-4.
Don't mix everything. So you, Luke Stein and Drucifer crash on startup, maybe for different causes.
This bug is for your issue.
Can you provide your crash ID in 10.0?
Does it happen in Safe Mode?
Does it happen with a new profile?
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ nsVoidArray::IndexOf(void*) ], [@ je_free | PL_DHashFreeTable ]
Ever confirmed: true
Summary: Crash [nsVoidArray::IndexOf(void*)] [@ je_free | PL_DHashFreeTable ] → Startup crash
Whiteboard: startupcrash
(In reply to Scoobidiver from comment #7)
> Don't mix everything. So you, Luke Stein and Drucifer crash on startup,
> maybe for different causes.
> This bug is for your issue.
> Can you provide your crash ID in 10.0?
> Does it happen in Safe Mode?
> Does it happen with a new profile?

Sorry but i didn't crashed.. I looked-up the Crash Report from Luke Stein and there was not a related Bug for it so i filed a bug.
(In reply to mha007 from comment #8)
> Sorry but i didn't crashed.. I looked-up the Crash Report from Luke Stein
Luke Stein hasn't provided crash reports and Drucifer has a BSOD and crashes in Fx 9.
This signature shows up in explosive crash reports on Fx 9.0.1.

Here is the stack:
Frame 	Module 	Signature [Expand] 	Source
0 	mozutils.dll 	je_free 	memory/jemalloc/jemalloc.c:6260
1 	xul.dll 	PL_DHashFreeTable 	obj-firefox/xpcom/build/pldhash.cpp:120
2 	xul.dll 	ChangeTable 	obj-firefox/xpcom/build/pldhash.cpp:599
3 	xul.dll 	xul.dll@0x1680bf 	
4 	xul.dll 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.cpp:789
5 	xul.dll 	nsTHashtable<nsBaseHashtableET<nsStringHashKey,nsRefPtr<gfxFontEntry> > >::Clear 	obj-firefox/dist/include/nsTHashtable.h:251
6 	xul.dll 	nsCategoryManager::~nsCategoryManager 	xpcom/components/nsCategoryManager.cpp:486
7 	xul.dll 	xul.dll@0xc9a99b 	
8 	xul.dll 	ScopedXPCOMStartup::~ScopedXPCOMStartup 	toolkit/xre/nsAppRunner.cpp:1084
9 	xul.dll 	XRE_main 	
10 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:107
11 	firefox.exe 	firefox.exe@0x4033 	
12 	firefox.exe 	__tmainCRTStartup 	crtexe.c:594
13 	firefox.exe 	_SEH_epilog4 	
14 	kernel32.dll 	BaseThreadInitThunk 	
15 	ntdll.dll 	__RtlUserThreadStart 	
16 	kernel32.dll 	LoadStringByReference 	
17 	kernel32.dll 	LoadStringByReference
Crash Signature: [@ je_free | PL_DHashFreeTable]
Component: Untriaged → XPCOM
Product: Firefox → Core
QA Contact: untriaged → xpcom
Summary: Startup crash → Startup crash @ je_free | PL_DHashFreeTable
Version: 10 Branch → 9 Branch
Crash Signature: [@ je_free | PL_DHashFreeTable] → [@ je_free | PL_DHashFreeTable] [@ je_free | PL_DHashFreeTable | ChangeTable]
Depends on: 716345
Summary: Startup crash @ je_free | PL_DHashFreeTable → Startup crash @ je_free | PL_DHashFreeTable | ChangeTable
These all have mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems in the stack, and some have mozilla::FrameLayerBuilder::AddThebesDisplayItem, so it looks layout-related. I looked at a few functions on the stack, and none seem to have changed recently.  The most recent is some changes in bug 741682, but that was at the end of July.

Some examples:
https://crash-stats.mozilla.com/report/index/489e3c97-afbf-41be-a53e-637222120808
https://crash-stats.mozilla.com/report/index/1a399733-e097-4e30-afad-886dd2120808
https://crash-stats.mozilla.com/report/index/b99d1a32-4738-4d88-a832-bad032120808
Unfortunately these stacks are somewhat bogus since FrameLayerBuilder::AddThebesDisplayItem doesn't call anything else in FrameLayerBuilder. So it's difficult to reason about what might be going on from the stacks.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.