Closed Bug 682313 Opened 11 years ago Closed 11 years ago

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


(Core :: IPC, defect)

Windows XP
Not set



Tracking Status
firefox9 + ---


(Reporter: marcia, Assigned: khuey)


(Depends on 1 open bug)


(Keywords: crash, regression, Whiteboard: fixed-in-bs [qa?])

Crash Data


(1 file)

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
Many of the comments mention crashing after coming out of hibernation mode.
Crash Signature: [@ je_free | mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage() ] Search Mozilla Support for Help → [@ je_free | mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage() ]
_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)
(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.
I tried to reproduce this on a few different machines but so far no luck yet.
Assignee: nobody → khuey
It's not immediately clear what's wrong here ... we export a wcsdup from jemalloc.  I'll look into this.
Never mind, it is pretty clear.  Should be an easy fix.
Attached patch Potential fixSplinter Review
Need to do a clobber to verify the linkage is right.
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.
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
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.
Attachment #556933 - Flags: review?(jmathies) → review+
A friend is crashing like on Vista.

Is this the same bug or should a new one be filed?
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.
Crash Signature: [@ je_free | mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage() ] → [@ je_free | mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage() ] @ je_free | CallWindowProcCrashProtected ]

Can we test for this somehow?  Just hitting this code path would be enough to trigger the crash ...
Closed: 11 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
(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.
Adding more signatures per bug 683248 comment #4.
Crash Signature: [@ je_free | mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage() ] @ je_free | CallWindowProcCrashProtected ] → [@ je_free | mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage() ] [@ je_free | CallWindowProcCrashProtected ] [@ je_free | DefWindowProcW ] [@ je_free | nsWindow::DealWithPopups(HWND__*, unsigned int unsigned __int64,…
Other than checking Socorro, is there a testcase QA can use to verify this fix?
Whiteboard: fixed-in-bs → fixed-in-bs [qa?]
You need to log in before you can comment on or make changes to this bug.