Closed Bug 443772 Opened 16 years ago Closed 16 years ago

firefox 3 hangs on startup before select profile when launching for links clicked from other programs (including thunderbird)

Categories

(Toolkit :: Startup and Profile System, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 395891

People

(Reporter: keith, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 When clicking a link from another program (for example, in an email in Thunderbird), when Firefox is NOT CURRENTLY RUNNING, Firefox hangs before even showing the select profile screen. Viewing the properties of firefox.exe using Process Explorer from Sysinternals shows 6 threads, with start addresses of: firefox.exe+0x15a0 xul.dll!gfxPattern::NgfxPattern+0x55 MOZCRT19.dll!endthreadex+0xa0 mwsock.dll!WSPStartup+0x1254 MOZCRT19.dll!endthreadex+0xa0 MOZCRT19.dll!endthreadex+0xa0 The stack traces for each of these threads (as shown by Process Explorer) are, in order: ntoskrnl.exe+0x584d ntoskrnl.exe!KeQueryRuntimeThread+0x5e8 ntoskrnl.exe!CcPurgeCacheSection+0x240 win32k.sys+0x2f60 win32k.sys+0x3766 win32k.sys+0x3783 ntdll.dll!KiFastSystemCallRet xul.dll!gfxPDFSurface::`vftable'+0x7d4 xul.dll!NS_CycleCollectorForget_P+0x1a5d0 ntoskrnl.exe!ZwAssignProcessToJobObject+0x15 ntoskrnl.exe!KeQueryRuntimeThread+0x5e8 ntoskrnl.exe!CcPurgeCacheSection+0x240 ntoskrnl.exe!NtQueryInformationToken+0xb4e ntoskrnl.exe!ZwSetSystemInformation+0x23 ntdll.dll!KiFastSystemCallRet kernel32.dll!WaitForSingleObject+0x12 xul.dll!gfxPattern::~gfxPattern+0x68 ntoskrnl.exe!ZwAssignProcessToJobObject+0x15 ntoskrnl.exe!KeQueryRuntimeThread+0x5e8 ntoskrnl.exe!CcPurgeCacheSection+0x240 ntoskrnl.exe!NtQueryInformationToken+0xb4e ntoskrnl.exe!ZwSetSystemInformation+0x23 ntdll.dll!KiFastSystemCallRet kernel32.dll!WaitForSingleObject+0x12 nspr4.dll!PR_MD_WAIT_CV+0xc9 nspr4.dll!PR_GetPrimordialCPU+0x78 nspr4.dll!PR_WaitCondVar+0x3b xul.dll!NS_NewLocalFile_P+0x6a24 xul.dll!gfxContext::GetCairo+0xe261 ntoskrnl.exe!ZwAssignProcessToJobObject+0x15 ntoskrnl.exe!KeQueryRuntimeThread+0x5e8 ntoskrnl.exe!CcPurgeCacheSection+0x240 ntoskrnl.exe!NtQueryInformationToken+0x1f87 ntoskrnl.exe!ZwSetSystemInformation+0x23 ntdll.dll!KiFastSystemCallRet kernel32.dll!GetModuleFileNameA+0x1b4 ntoskrnl.exe!ZwAssignProcessToJobObject+0x15 ntoskrnl.exe!KeQueryRuntimeThread+0x5e8 ntoskrnl.exe!CcPurgeCacheSection+0x240 ntoskrnl.exe!NtQueryInformationToken+0xb4e ntoskrnl.exe!ZwSetSystemInformation+0x23 ntdll.dll!KiFastSystemCallRet mswsock.dll+0x5fa7 WS2_32.dll!select+0xa7 nspr4.dll+0x209cd nspr4.dll!PR_Poll+0x13 ntoskrnl.exe!ZwAssignProcessToJobObject+0x15 ntoskrnl.exe!KeQueryRuntimeThread+0x5e8 ntoskrnl.exe!CcPurgeCacheSection+0x240 ntoskrnl.exe!NtQueryInformationToken+0x16c6 ntoskrnl.exe!ZwSetSystemInformation+0x23 ntdll.dll!KiFastSystemCallRet kernel32.dll!WaitForMultipleObjects+0x18 xul.dll!gfxRGBA::gfxRGBA+0x2032 xul.dll!gfxContext::GetCairo+0xe261 If Firefox is ALREADY RUNNING there is no problem and the link opens properly in a new tab. Reproducible: Always Steps to Reproduce: 1. Click on a link in another program (say, Thunderbird) when Firefox is NOT open. Actual Results: The firefox.exe process starts, but no UI is displayed. Expected Results: The "select profile" screen should appear, allowing you to select the profile to use to open the link with. This behavior has only started since upgrading to Firefox 3. I have 3 user profiles in Firefox.
I should also mention that viewing the process information using the Windows Debugger shows that the firefox.exe program was launched with the following command line arguments: firefox.exe -requestpending -osint -url [the url that was clicked on in step 1] I will try and see if I can manually cause the problem by using this command line syntax.
I have confirmed that the command line: firefox.exe -requestpending -osint -url [any URL] Will cause the same behavior. I have no idea what these command line parameters mean, as they don't appear to be documented: http://developer.mozilla.org/en/docs/Command_Line_Options Hopefully though this will help point someone to the source of this behavior.
Dup of recently fixed Bug 395891?
I think you may be right. Though I never would have found that bug based on its description!
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.