Last Comment Bug 682313 - Firefox 9.0a1 Crash [@ je_free | mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage() ]
: Firefox 9.0a1 Crash [@ je_free | mozilla::ipc::windows::DeferredSettingChange...
fixed-in-bs [qa?]
: crash, regression
Product: Core
Classification: Components
Component: IPC (show other bugs)
: Trunk
: x86 Windows XP
: -- critical with 1 vote (vote)
: mozilla9
Assigned To: Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)
: Bill McCloskey (:billm)
Depends on: 683248
  Show dependency treegraph
Reported: 2011-08-26 09:38 PDT by Marcia Knous [:marcia - use ni]
Modified: 2011-11-21 16:53 PST (History)
11 users (show)
khuey: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Potential fix (572 bytes, patch)
2011-08-30 11:33 PDT, Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)
jmathies: review+
Details | Diff | Splinter Review

Description Marcia Knous [:marcia - use ni] 2011-08-26 09:38:14 PDT
Seen while looking at crash stats. Crashes started showing up using the 2011082500 build.|%20mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage%28%29. Concentration of crashes is higher on Win XP.

Possible pushlog regression range:

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/
24 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/
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 - use ni] 2011-08-29 11:38:34 PDT
Many of the comments mention crashing after coming out of hibernation mode.
Comment 2 Makoto Kato [:m_kato] 2011-08-30 01:37:49 PDT
_wcsdup() calls MSVCRT's _wcsdup instead of jemalloc.dll...  This is a regression from new style jemalloc.

0:015> u
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
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 2011-08-30 02:24:03 PDT
(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 - use ni] 2011-08-30 09:54:12 PDT
I tried to reproduce this on a few different machines but so far no luck yet.
Comment 5 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-30 11:28:22 PDT
It's not immediately clear what's wrong here ... we export a wcsdup from jemalloc.  I'll look into this.
Comment 6 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-30 11:31:11 PDT
Never mind, it is pretty clear.  Should be an easy fix.
Comment 7 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-30 11:33:21 PDT
Created attachment 556933 [details] [diff] [review]
Potential fix

Need to do a clobber to verify the linkage is right.
Comment 8 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-30 12:02:21 PDT
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 [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-30 12:36:37 PDT
With this patch:

              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 [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-30 12:43:48 PDT
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 2011-08-30 13:28:48 PDT
A friend is crashing like on Vista.

Is this the same bug or should a new one be filed?
Comment 13 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-30 14:13:28 PDT
Comment 14 Pratik 2011-08-30 14:55:31 PDT
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 [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-31 08:12:12 PDT

Can we test for this somehow?  Just hitting this code path would be enough to trigger the crash ...
Comment 16 Jim Mathies [:jimm] 2011-08-31 08:54:31 PDT
(In reply to Kyle Huey [:khuey] ( from comment #15)
> 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 2011-09-02 09:35:04 PDT
Adding more signatures per bug 683248 comment #4.
Comment 18 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-11-21 16:53:08 PST
Other than checking Socorro, is there a testcase QA can use to verify this fix?

Note You need to log in before you can comment on or make changes to this bug.