Investigate cause of unreported startup crashes in 680927

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
7 years ago
7 years ago

People

(Reporter: akeybl, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
From https://bugzilla.mozilla.org/show_bug.cgi?id=680927#c48

(In reply to Ian Gregory from comment #48)
> I'm still getting this crash with Fx 10.0b1 - though neither the Mozilla
> crash reporter nor the Windows winqual system is catching it - Firefox just
> exits silently. I can easily work around the issue but I wonder how many
> users are being affected by this bug but are not visible due to the fact
> that crash reports have not been sent for this issue since Fx 7.0
(Reporter)

Updated

7 years ago
Depends on: 680927
(Reporter)

Updated

7 years ago
No longer depends on: 680927
(Reporter)

Updated

7 years ago
Depends on: 680927
How do we know this is the same issue if there aren't any reports being sent anywhere? Has anyone else been able to reproduce this behavior?
(Reporter)

Comment 2

7 years ago
(In reply to Ted Mielczarek [:ted, :luser] from comment #1)
> How do we know this is the same issue if there aren't any reports being sent
> anywhere? Has anyone else been able to reproduce this behavior?

I've CC'd Ian for help in answering your question. The intent of this bug was to separate out the new silent startup crash report from the previous bug.

Comment 3

7 years ago
I can tell it's the same issue as shutting down Oracle ESSO allows Firefox to start cleanly. If I start Oracle ESSO and then start Firefox, I see the taskbar icon animate to the 'running' state then back to the 'inactive' state 2-3 seconds later.

In Fx 7.0, the crash reporter picked up the issue.

In Fx 8.0, the crash reporter no longer picked up the issue, but there was still an entry in the Windows Event Log:

Faulting application name: firefox.exe, version: 8.0.0.4288, time stamp: 0x4e8342f6
Faulting module name: mozmolt0.dll, version: 7.0.1.151, time stamp: 0x4b1d8f7f
Exception code: 0xc0000005
Fault offset: 0x0000138e
Faulting process id: 0x1fd8
Faulting application start time: 0x01cc84c2267e6ad9
Faulting application path: C:\Users\GregorI\AppData\Local\Mozilla Firefox\firefox.exe
Faulting module path: C:\Program Files\Passlogix\v-GO SSO\Helper\Moz\mozmolt0.dll
Report Id: d8f78760-f0b5-11e0-9500-68b599f6eede

I can't recall the behaviour from Fx 9, but Fx 10 behaves as stated at the start of this comment.

Comment 4

7 years ago
If you are interested in launching Firefox under a debugger to get a crash stack, that would be very helpful: https://developer.mozilla.org/En/Using_the_Mozilla_symbol_server has instructions on using the free MSVC express edition so that you can debug our release builds.

It's clear from the report that mozmolt0.dll is crashing, which is not a Mozilla DLL, so this is definitely caused by third-party software.

Comment 5

7 years ago
I'll try and get a debug build of Fx running on my laptop at the weekend and see if I can get a stack.

Having said that, I've done some further testing, and it appears in the Fx 10 builds Firefox is actually hanging indefinitely rather than crashing - on startup the process stays in the background consuming CPU. If ESSO is started whilst Fx is already running, the Fx window freezes, greys and displays the "Not Responding" window title. So I may not be able to get a crash stack.
You don't need a debug build. With the link in comment 4, you can get a stack from our release builds. If this is a hang, you can still attach a debugger and break into the application to find out where it's hanging.

Comment 7

7 years ago
Created attachment 586112 [details]
Windbg output

Attached Windbg output - issued break on hung thread
This is pretty clearly that
This is pretty clearly that mozcomp.dll doing something bad and causing a hang. I don't think there's anything more definitive we can say about it without access to its source.

Comment 10

7 years ago
Fair enough. I don't suppose there is a way for firefox to detect a hang in a third party module and react appropriately (perhaps by crashing?) is there?

The current behavior gives no indication of the cause of the issue other than "Firefox won't load"
We do have some code for hang monitoring (bug 429592), but it's currently preffed-off because we trip it entirely too much in actual usage right now.

Comment 12

7 years ago
Yeah, I don't think there's realistically anything we can do about this. Resolving the bug.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.