474008 - crash [@ arena_dalloc_small ]

Status: RESOLVED INCOMPLETE

(Core :: General, defect)

Description

[Kevin Brosnan]

0  	mozcrt19.dll  	arena_dalloc_small  	jemalloc.c:4097
1 	mozcrt19.dll 	arena_dalloc 	jemalloc.c:4199
2 	mozcrt19.dll 	free 	jemalloc.c:6017
3 	xul.dll 	XPT_DestroyArena 	mozilla/xpcom/typelib/xpt/src/xpt_arena.c:177
4 	xul.dll 	xptiWorkingSet::~xptiWorkingSet() 	mozilla/xpcom/reflect/xptinfo/src/xptiWorkingSet.cpp:229
5 	xul.dll 	xptiInterfaceInfoManager::AutoRegisterInterfaces() 	mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp:1959
6 	xul.dll 	NS_InitXPCOM3_P 	mozilla/xpcom/build/nsXPComInit.cpp:654
7 	xul.dll 	ScopedXPCOMStartup::Initialize() 	mozilla/toolkit/xre/nsAppRunner.cpp:982
8 	xul.dll 	ImportProfiles 	mozilla/toolkit/xre/nsAppRunner.cpp:1821
9 	xul.dll 	xul.dll@0x2ef295 	
10 	xul.dll 	XRE_main 	mozilla/toolkit/xre/nsAppRunner.cpp:2917
11 	firefox.exe 	wmain 	mozilla/toolkit/xre/nsWindowsWMain.cpp:87
12 	firefox.exe 	firefox.exe@0x217f 	
13 	kernel32.dll 	kernel32.dll@0x17066

User states that this happens on first run of Firefox. He cleared out c:\program files\mozilla firefox\ and %appdata%\mozilla

No obvious malware in the stack.

Comment 1

[Kevin Brosnan]

User was previously using Firefox 2, since bz asked it might be important.

Comment 2

[Benjamin Smedberg]

There's not a lot to go on here... is it this same stack every time? It's possibly (likely?) heap corruption, since it seems unlikely that the xptinfo code is directly causing double-free or anything like that: the xptiWorkingSet is an automatic variable.

Comment 3

[Ludovic Hirlimann [:Usul]]

http://crash-stats.mozilla.com/report/index/968566bc-5420-43ce-92be-3da7c2090303
http://crash-stats.mozilla.com/report/index/bb3e776a-f13d-42e2-a5a9-40c172090308
http://crash-stats.mozilla.com/report/index/dac07390-a623-4819-8f44-c7ad92090309

> There's not a lot to go on here... is it this same stack every time? It's
> possibly (likely?) heap corruption, since it seems unlikely that the xptinfo
> code is directly causing double-free or anything like that: the xptiWorkingSet
> is an automatic variable.

Here is another set of stack that end up crashing at the same place. so could it be that the calling code is doing a double free ? If so I shall probably open a new issue right ?

Comment 4

[Stuart Parmenter]

double free or mismatched allocators (external extension?)

Comment 5

[Wayne Mery (:wsmwk)]

still needed?

Comment 6

[Wayne Mery (:wsmwk)]

I think comment 2 sums it up.