682313 - Firefox 9.0a1 Crash [@ je_free | mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage() ]

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Marcia Knous [:marcia]]

Seen while looking at crash stats. Crashes started showing up using the 2011082500 build. https://crash-stats.mozilla.com/report/list?signature=je_free%20|%20mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage%28%29. Concentration of crashes is higher on Win XP.

https://crash-stats.mozilla.com/report/index/81031ed8-8152-44fd-a143-b004c2110826

Possible pushlog regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=198c7de0699d&tochange=e58e98a89827

Frame 	Module 	Signature [Expand] 	Source
0 	jemalloc.dll 	je_free 	memory/jemalloc/jemalloc.c:6215
1 	xul.dll 	mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage 	ipc/glue/WindowsMessageLoop.cpp:1071
2 	xul.dll 	mozilla::ipc::windows::DeferredSettingChangeMessage::`scalar deleting destructor' 	
3 	xul.dll 	mozilla::ipc::RPCChannel::RefCountedTask::~RefCountedTask 	obj-firefox/dist/include/nsAutoPtr.h:104
4 	xul.dll 	nsAutoPtr<mozilla::net::ChannelEvent>::`scalar deleting destructor' 	
5 	xul.dll 	nsTArrayElementTraits<nsAutoPtr<PresShell::nsDelayedEvent> >::Destruct 	obj-firefox/dist/include/nsTArray.h:310
6 	xul.dll 	nsTArray<nsAutoPtr<mozilla::ipc::windows::DeferredMessage>,nsTArrayDefaultAllocator>::DestructRange 	obj-firefox/dist/include/nsTArray.h:1147
7 	xul.dll 	nsTArray<nsAutoPtr<gfxTextRun>,nsTArrayDefaultAllocator>::RemoveElementsAt 	obj-firefox/dist/include/nsTArray.h:875
8 	xul.dll 	nsTArray<nsAutoPtr<mozilla::net::ChannelEvent>,nsTArrayDefaultAllocator>::Clear 	obj-firefox/dist/include/nsTArray.h:886
9 	xul.dll 	nsTArray<nsAutoPtr<mozilla::net::ChannelEvent>,nsTArrayDefaultAllocator>::~nsTArray<nsAutoPtr<mozilla::net::ChannelEvent>,nsTArrayDefaultAllocator> 	obj-firefox/dist/include/nsTArray.h:408
10 	xul.dll 	nsTArray<nsAutoPtr<mozilla::ipc::windows::DeferredMessage>,nsTArrayDefaultAllocator>::`scalar deleting destructor' 	
11 	xul.dll 	nsAutoPtr<nsTArray<nsAutoPtr<mozilla::ipc::windows::DeferredMessage>,nsTArrayDefaultAllocator> >::~nsAutoPtr<nsTArray<nsAutoPtr<mozilla::ipc::windows::DeferredMessage>,nsTArrayDefaultAllocator> > 	obj-firefox/dist/include/nsAutoPtr.h:104
12 	xul.dll 	`anonymous namespace'::DeferredMessageHook 	ipc/glue/WindowsMessageLoop.cpp:162
13 	user32.dll 	DispatchHookW 	
14 	user32.dll 	CallHookWithSEH 	
15 	user32.dll 	__fnHkINLPMSG 	
16 	ntdll.dll 	KiUserCallbackDispatcher 	
17 	xul.dll 	`anonymous namespace'::ProcessOrDeferMessage 	ipc/glue/WindowsMessageLoop.cpp:342
18 	user32.dll 	NtUserPeekMessage 	
19 	xul.dll 	nsAppShell::ProcessNextNativeEvent 	widget/src/windows/nsAppShell.cpp:339
20 	xul.dll 	nsBaseAppShell::OnProcessNextEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:324
21 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:595
22 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:134
23 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:201
24 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:175
25 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:189
26 	xul.dll 	nsAppShell::Run 	widget/src/windows/nsAppShell.cpp:261
27 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:224
28 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3545
29 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:107
30 	firefox.exe 	__tmainCRTStartup 	crtexe.c:594
31 	kernel32.dll 	BaseProcessStart

Comment 1

[Marcia Knous [:marcia]]

Many of the comments mention crashing after coming out of hibernation mode.

Comment 2

[Makoto Kato [:m_kato]]

_wcsdup() calls MSVCRT's _wcsdup instead of jemalloc.dll...  This is a regression from new style jemalloc.

0:015> u
xul!mozilla::ipc::windows::DeferredSettingChangeMessage::DeferredSettingChangeMessage+0x13:
5fbc55b5 56              push    esi
5fbc55b6 e8cdfff8ff      call    xul!mozilla::ipc::windows::DeferredSendMessage::DeferredSendMessage (5fb55588)
5fbc55bb 33c0            xor     eax,eax
5fbc55bd 394518          cmp     dword ptr [ebp+18h],eax
5fbc55c0 c706bc613760    mov     dword ptr [esi],offset xul!mozilla::ipc::windows::DeferredSettingChangeMessage::`vftable' (603761bc)
5fbc55c6 740a            je      xul!mozilla::ipc::windows::DeferredSettingChangeMessage::DeferredSettingChangeMessage+0x30 (5fbc55d2)
5fbc55c8 ff7518          push    dword ptr [ebp+18h]
5fbc55cb ff15dc590d60    call    dword ptr [xul!_imp___wcsdup (600d59dc)]

0:011> dd 600d59dc l1
600d59dc  741b4cad

0:015> u 741b4cad
MSVCR80!wcsdup:
741b4cad 53              push    ebx
741b4cae 8b5c2408        mov     ebx,dword ptr [esp+8]
741b4cb2 55              push    ebp
741b4cb3 33ed            xor     ebp,ebp
741b4cb5 3bdd            cmp     ebx,ebp
741b4cb7 7504            jne     MSVCR80!wcsdup+0x10 (741b4cbd)
741b4cb9 33c0            xor     eax,eax
741b4cbb eb40            jmp     MSVCR80!wcsdup+0x50 (741b4cfd)

Comment 3

[etienne.massip]

(In reply to Marcia Knous [:marcia] from comment #1)
> Many of the comments mention crashing after coming out of hibernation mode.

Not only hibernation but also from when unlocking screen.

Comment 4

[Marcia Knous [:marcia]]

I tried to reproduce this on a few different machines but so far no luck yet.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

It's not immediately clear what's wrong here ... we export a wcsdup from jemalloc.  I'll look into this.

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Never mind, it is pretty clear.  Should be an easy fix.

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Potential fix

Need to do a clobber to verify the linkage is right.

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

bent points out that we want some sort of mechanism in place to make sure we don't hit this again with a different symbol.  I have a plan; bug forthcoming.

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

With this patch:

    jemalloc.dll
              10934C28 Import Address Table
              10C8A28C Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                    2 _wcsdup
                    C strdup
                    6 jemalloc_stats
                    7 malloc
                    4 free
                    8 malloc_usable_size
                    5 frex
                    3 calloc
                    F wcsdup
                    B realloc

Comment 10

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I also skimmed the list of imports from the CRT and didn't see anything that looked sketchy.  The blocking bug will cover automating this check.

Comment 11

[alex_mayorga]

A friend is crashing like https://crash-stats.mozilla.com/report/index/bp-e5f7b0ae-f763-47a4-ab94-fa94a2110830 on Vista.

Is this the same bug or should a new one be filed?

Comment 12

[Yakove]

Crash on Win7 https://crash-stats.mozilla.com/report/index/bp-ba812e04-cc4a-4665-9804-92efa2110830

Comment 13

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/projects/build-system/rev/19a5f6177257

Comment 14

[Pratik]

happened to me 3 times today when unlocking the screen after a long time (screen saver/blank screen was active) and firefox was the application in focus.

Comment 15

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/mozilla-central/rev/19a5f6177257

Can we test for this somehow?  Just hitting this code path would be enough to trigger the crash ...

Comment 16

[Jim Mathies [:jimm]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #15)
> http://hg.mozilla.org/mozilla-central/rev/19a5f6177257
> 
> Can we test for this somehow?  Just hitting this code path would be enough
> to trigger the crash ...

Don't think so. Hitting this is completely random, it involves catching a certain windowing event while we're in the ipc wait for response loop.

Comment 17

[Robert Kaiser]

Adding more signatures per bug 683248 comment #4.

Comment 18

[u279076]

Other than checking Socorro, is there a testcase QA can use to verify this fix?