Closed
Bug 694432
Opened 13 years ago
Closed 13 years ago
Nightly fails to start on Windows 8 since 20111012 build
Categories
(Core :: Security, defect)
Tracking
()
VERIFIED
FIXED
mozilla10
People
(Reporter: sidrabbit, Assigned: ehsan.akhgari)
References
Details
(Keywords: regression, Whiteboard: [qa!])
Attachments
(3 files, 1 obsolete file)
61.64 KB,
text/plain
|
Details | |
2.15 KB,
patch
|
asa
:
approval-mozilla-aurora+
asa
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
2.87 KB,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
I'm using Windows 8 Developer Preview. Nightly builds 20111012 and later just won't start. The process appears in the Task Manager for a few seconds, then disappears, but application window never shows up. Launching Nightly with Shift button doesn't help. Last working Nightly build was 20111011.
The breaking changeset seems to be http://hg.mozilla.org/mozilla-central/rev/e0ae39a3298e. Bug 677797 seems suspiciously.
Windows 8 Developer Preview x64 - the same problem. How can it be solved?
Comment 4•13 years ago
|
||
Confirming based on two bugzilla reports and a couple more reports on Mozillazine. Not sure if security is the right component for a non-security bug caused by a security fix, but...
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: General → Security
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → toolkit
Updated•13 years ago
|
Keywords: regression
Source Nightly Summary Stopped working Date 14.10.2011 21:28 Status Report sent Description Faulting Application Path: C:\Program Files (x86)\Mozilla\Firefox\Nightly\firefox.exe Problem signature Problem Event Name: APPCRASH Application Name: firefox.exe Application Version: 10.0.0.4304 Application Timestamp: 4e9834b9 Fault Module Name: ntdll.dll Fault Module Version: 6.2.8102.0 Fault Module Timestamp: 4e546498 Exception Code: c0000005 Exception Offset: 00063450 OS Version: 6.2.8102.2.0.0.256.74 Locale ID: 1031 Additional Information 1: 5861 Additional Information 2: 5861822e1919d7c014bbb064c64908b2 Additional Information 3: 7812 Additional Information 4: 78125405641511429762037848645157 Extra information about the problem Bucket ID: 06fc03c33bb3edbab6a2259a72b3ce6a ------------------------------------------------------ Firefox Beta and Aurora are working (exept the GUI glitches)
Comment 10•13 years ago
|
||
Assignee: nobody → ehsan
Assignee | ||
Comment 11•13 years ago
|
||
I could reproduce this. I will investigate.
Assignee | ||
Comment 12•13 years ago
|
||
It seems like Windows 8's LdrLoadDll has been changed to accept more values inside the filePath argument. The cause of the crash is that we're passed a value of 1 with that function the first time when we're trying to load user32.dll, and then we pass that to SearchPathW which causes a crash. This isn't technically a regression from bug 677797 in the sense that on Windows 8, we would still crash without that patch if we're trying to load a DLL which has some of its versions blacklisted. Therefore I think we need to take this patch (well, it's equivalent which would apply on Aurora and Beta) on those branches as well.
Attachment #567368 -
Flags: review?(benjamin)
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Comment 13•13 years ago
|
||
Attachment #567369 -
Flags: approval-mozilla-beta?
Attachment #567369 -
Flags: approval-mozilla-aurora?
Comment 14•13 years ago
|
||
Comment on attachment 567368 [details] [diff] [review] Patch (v1) IsBadStringPtr is almost never the value we want to be using. I suggest instead, if we don't actually have documentation or understanding of the problem, to use the check (intptr_t(filePath) < 1024))
Attachment #567368 -
Flags: review?(benjamin) → review-
Assignee | ||
Comment 15•13 years ago
|
||
Attachment #567368 -
Attachment is obsolete: true
Attachment #567454 -
Flags: review?(benjamin)
Updated•13 years ago
|
Attachment #567454 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 16•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/a7b4442baf9d
Target Milestone: --- → mozilla10
Comment 17•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a7b4442baf9d
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 18•13 years ago
|
||
I tested to see if this bug is verified fixed and got the following result for Mozilla Central:
Verified Fixed - Mozilla/5.0 (Windows NT 6.2; rv:10.0a1) Gecko/20111019 Firefox/10.0a1
-> I tested on the Windows 8 Developer Preview
-> The Nightly build before the landing of the patch doesn't load as noted in the Description
-> The first Nightly build (19 October) after the landing of the patch loads as expected
> Created attachment 567369 [details] [diff] [review] [diff] [details] [review]
> Patch for aurora and beta
Are these patches landed yet? If not, the status of this bug will be changed to verified when testing on this branches is done, as well.
Why do we need this on Aurora and Beta? Windows 8 isn't a supported platform for Gecko 8 or 9.
Comment 20•13 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #19) > Why do we need this on Aurora and Beta? Windows 8 isn't a supported > platform for Gecko 8 or 9. To get more testing from the users of these branches on windows 8 ?
Assignee | ||
Comment 21•13 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #19) > Why do we need this on Aurora and Beta? Windows 8 isn't a supported > platform for Gecko 8 or 9. Technically it's not a supported platform for Gecko 10 either! But without this, if there's a DLL on a Windows 8 system which we blacklist, we'll just crash. I think that if we can do something safe to fix that problem (which is what this patch does), we should take it. But I'll leave it to drivers in order to make a decision about this.
Updated•13 years ago
|
Attachment #567369 -
Flags: approval-mozilla-beta?
Attachment #567369 -
Flags: approval-mozilla-beta+
Attachment #567369 -
Flags: approval-mozilla-aurora?
Attachment #567369 -
Flags: approval-mozilla-aurora+
Assignee | ||
Comment 22•13 years ago
|
||
http://hg.mozilla.org/releases/mozilla-aurora/rev/2eee5fa83a4d http://hg.mozilla.org/releases/mozilla-beta/rev/09455d5e1501
Comment 23•13 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #22) > http://hg.mozilla.org/releases/mozilla-aurora/rev/2eee5fa83a4d > http://hg.mozilla.org/releases/mozilla-beta/rev/09455d5e1501 I tested to see if this bug is verified considering the landing of the patches on Beta and Aurora channels, Windows 8 Developer Preview: Verified Fixed on: Mozilla/5.0 (Windows NT 6.2; rv:8.0) Gecko/20100101 Firefox/8.0 (Beta) Mozilla/5.0 (Windows NT 6.2; rv:9.0a2) Gecko/20111023 Firefox/9.0a2 (Aurora) Considering these and the verifications did on central (comment 18), setting this bug's status as Verified and changing the keyword to qa! (all channels)
Status: RESOLVED → VERIFIED
Whiteboard: [qa!]
Comment 24•13 years ago
|
||
---------------------------------[ Triage Comment ]--------------------------------- Windows 8 is pre-release and isn't supported by any shipping version of Firefox, therefore we will not track it explicitly. Of course, the bug is already fixed but if for some reason it becomes unfixed we don't need visibility because of our lack of support (and I bet Asa and Robert Strong's team are all over this).
Blocks: 728429
No longer blocks: 728429
You need to log in
before you can comment on or make changes to this bug.
Description
•