529292 - Using profile manager when Google Desktop is installed causes a crash and a zombie process running [@ nsXPCWrappedJS::Release]

Status: RESOLVED INVALID

(Core :: XPConnect, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: WinDBG stack

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4

For users who have Google Desktop Search v5 (5.9.909.2235) installed a zombie process will exist in memory after a profile has been chosen. When starting Firefox with WinDBG you can see that right after the profile selection the current process dies due to a null pointer dereference. That will cause that files are still in use after the user exits Firefox normally.

Steps:
1. Install a 3.5.x version of Firefox in the default location
2. Install Google Desktop Search v5 (http://desktop.google.com/)
3. Start Firefox via the profile manager

After you have selected a profile you will notice that a second process of Firefox is created but the first one is still present in memory. Even after shutdown this process is not closed. Running step 3 several times will add more and more zombie processes.

Stack:

001cfc90 723690c3 xul!nsXPCWrappedJS::Release(void)+0x9 [e:\builds\moz2_slave\win32_build\build\js\src\xpconnect\src\xpcwrappedjs.cpp @ 229]
WARNING: Stack unwind information not available. Following frames may be wrong.
001cfcac 77a716ac GoogleDesktopMozilla!nsCOMPtr_base::~nsCOMPtr_base+0xc
001cfccc 77a6b58c ntdll!LdrpCallInitRoutine+0x14
001cfd6c 77a6b50e ntdll!LdrShutdownProcess+0x1a9
001cfd74 76fd41ec ntdll!RtlExitUserProcess+0x64
001cfd88 724f179e kernel32!ExitProcess+0x12
001cfd94 724f1b66 MOZCRT19!__crtExitProcess(int status = 1917786014)+0x2e [e:\builds\moz2_slave\win32_build\build\obj-firefox\memory\jemalloc\src\crt0dat.c @ 683]
001cfdcc 724f1bee MOZCRT19!doexit(int code = 0, int quick = 9531644, int retcaller = 1917786983)+0x116 [e:\builds\moz2_slave\win32_build\build\obj-firefox\memory\jemalloc\src\crt0dat.c @ 596]
001cfddc 012f1449 MOZCRT19!exit(int code = 1996345577)+0xe [e:\builds\moz2_slave\win32_build\build\obj-firefox\memory\jemalloc\src\crt0dat.c @ 398]
001cfe14 76fdd0e9 firefox!__tmainCRTStartup(void)+0x169 [e:\builds\moz2_slave\win32_build\build\obj-firefox\memory\jemalloc\src\crtexe.c @ 605]
001cfe20 77a719bb kernel32!BaseThreadInitThunk+0xe
001cfe60 77a7198e ntdll!__RtlUserThreadStart+0x23
001cfe78 00000000 ntdll!_RtlUserThreadStart+0x1b

Full analysis is attached.

I wonder how many people could be affected and will run in trouble when running e.g. a software update. It will always fail until those processes are killed.

This crash doesn't happen for 1.9.2 builds due to the new whitelisting feature.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It's definitely one cause that software updates cannot be applied. Checked that on Windows 7 now.

Comment 2

[Robert Strong (they/them - no direct email)]

Yep, this will prevent app update, add-on install/uninstall/update/enable/disable, etc. from working until the OS has been restarted and the app launched for the first time... not a lot if anything app update can do about this regretfully though app restart might be able to kill the app if the app is in a zombie state after a restart request.

Comment 3

[(not currently active) Ted Mielczarek]

Does this only happen when using the profile manager?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I have checked that a couple of times and yes, it only happens when the profile manager is involved. Starting Firefox with the profile directly via '-p' doesn't show that behavior.

Comment 5

[Benjamin Smedberg]

It appears that Google desktop has a static nsCOMPtr which they aren't releasing properly which is holding a nsXPCWrappedJS. That code usually locks nsXPConnect::GetRuntimeInstance()->GetMapLock(), although in this case that lock is probably already dead and somehow causing the deadlock. This is entirely a bug in google desktop.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Looking at bug 523922 we still don't have a contact to Google. I will send a mail via the webform. I hope we will get a response.

Comment 7

[RNicoletto]

Just FYI, I reported this bug (and possible workarounds) to Google over two month ago ==> http://tinyurl.com/ykmwzr4

After further investigation I discovered the "probably" the best workaround is simply rename/delete GoogleDesktopMozillaStub.js in C:\Program Files\Mozilla Firefox\components\. This file seems more related to Mozilla Thunderbird (??) than Firefox. Deleting/Renaming the file doesn't block GDS indexing Firefox activity.

Comment 8

[RNicoletto]

(In reply to comment #7)
> Just FYI, I reported this bug (and possible workarounds) to Google over two
> month ago ==> http://tinyurl.com/ykmwzr4
> 
> After further investigation I discovered the "probably" the best workaround is
> simply rename/delete GoogleDesktopMozillaStub.js in C:\Program Files\Mozilla
> Firefox\components\. This file seems more related to Mozilla Thunderbird (??)
> than Firefox. Deleting/Renaming the file doesn't block GDS indexing Firefox
> activity.

I forgot to mention that this bug is reproducible on Windows XP too.
I'm using Firefox 3.5.5 on Windows XP Pro SP3 with Google Desktop 5.9.0909.02235-en-pb.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #5)
> It appears that Google desktop has a static nsCOMPtr which they aren't
> releasing properly which is holding a nsXPCWrappedJS. That code usually locks
> nsXPConnect::GetRuntimeInstance()->GetMapLock(), although in this case that
> lock is probably already dead and somehow causing the deadlock. This is
> entirely a bug in google desktop.

Benjamin, does it mean we can move this bug over to extension compatibility? Do we have a contact at Google for that product?

Comment 10

[Wayne Mery (:wsmwk)]

Google Desktop is no longer a thing.