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.