Closed Bug 730051 Opened 13 years ago Closed 13 years ago

Appcrash after bug 728429 landed if Actual Window Manager is enabled

Categories

(Core :: Security, defect)

13 Branch
x86_64
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla13

People

(Reporter: tinybutstrong, Assigned: khuey)

References

Details

(Keywords: crash, regression)

Attachments

(1 file, 2 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120222 Firefox/13.0a1 Build ID: 20120222031223 Steps to reproduce: Upgrade Nightly to current build (02.23.12). Actual results: Crash on startup if Actual Window Manager (trial available in actualtools.com) is enabled. Expected results: Not to crash. Hourly build working http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1329960017/ , crashing one http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1329966198/ Working build c827c52c4603 | crashing 5e756e59a794 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c827c52c4603&tochange=5e756e59a794
Attached image App crash screenshot Windows 7 x64. (obsolete) (deleted) —
Blocks: 728429
Severity: normal → critical
Component: Untriaged → Security
Keywords: regression
Product: Firefox → Core
QA Contact: untriaged → toolkit
Target Milestone: --- → mozilla13
Status: UNCONFIRMED → NEW
Ever confirmed: true
Our DLL blocklist hook blocks one of their DLLs because SearchPathW can't find it, and then when they try to use it they crash.
Assignee: nobody → khuey
Right, so what's the solution?
Can you back the bug 728429 until a solution is found?
No. If this is a problem you can downgrade to Aurora until this is fixed.
Should I report the situation to ActualTools or the solution is restrict to Mozilla?
Keywords: crash
(In reply to TinyButStrong from comment #7) > Should I report the situation to ActualTools or the solution is restrict to > Mozilla? This is our bug.
Attached patch Patch (obsolete) (deleted) — Splinter Review
Pathless lookups need to work for DLLs that are already loaded.
Attachment #600119 - Attachment is obsolete: true
Attachment #600442 - Flags: review?(benjamin)
Blocks: 730274
Comment on attachment 600442 [details] [diff] [review] Patch I don't understand this patch yet: we printf_stderr that we're blocking the load but there's no failure code and we use GetFileVersionInfoSizeW/CheckASLR anyway? This happens in both code blocks...
(In reply to Benjamin Smedberg [:bsmedberg] from comment #10) > Comment on attachment 600442 [details] [diff] [review] > Patch > > I don't understand this patch yet: we printf_stderr that we're blocking the > load but there's no failure code and we use > GetFileVersionInfoSizeW/CheckASLR anyway? This happens in both code blocks... Er, that's just an oversight on my part. We definitely want to return failure codes there.
Attachment #600442 - Attachment is obsolete: true
Attachment #600442 - Flags: review?(benjamin)
Attached patch Patch (deleted) — Splinter Review
Lets try this again.
Attachment #601133 - Flags: review?(benjamin)
Attachment #601133 - Flags: review?(benjamin) → review+
Blocks: 731846
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Blocks: brikbot
Blocks: 732065
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: