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

RESOLVED FIXED in mozilla9

Status

()

Core
IPC
--
critical
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: marcia, Assigned: khuey)

Tracking

(Depends on: 1 bug, {crash, regression})

Trunk
mozilla9
x86
Windows XP
crash, regression
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox9+)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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
(Reporter)

Comment 1

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

Updated

6 years ago
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
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

6 years ago
(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.
(Reporter)

Comment 4

6 years ago
I tried to reproduce this on a few different machines but so far no luck yet.
Assignee: nobody → khuey
tracking-firefox9: --- → +
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.
Created attachment 556933 [details] [diff] [review]
Potential fix

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.
Depends on: 683248
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
Attachment #556933 - Flags: review?(jmathies)
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.

Updated

6 years ago
Attachment #556933 - Flags: review?(jmathies) → review+

Comment 11

6 years ago
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

6 years ago
Crash on Win7 https://crash-stats.mozilla.com/report/index/bp-ba812e04-cc4a-4665-9804-92efa2110830
http://hg.mozilla.org/projects/build-system/rev/19a5f6177257
Whiteboard: fixed-in-bs

Comment 14

6 years ago
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.

Updated

6 years ago
Crash Signature: [@ je_free | mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage() ] → [@ je_free | mozilla::ipc::windows::DeferredSettingChangeMessage::~DeferredSettingChangeMessage() ] @ je_free | CallWindowProcCrashProtected ]
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 ...
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla9

Comment 16

6 years ago
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) 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

6 years ago
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 _&hellip;
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.