Closed Bug 724413 Opened 14 years ago Closed 9 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: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.