Appcrash after bug 728429 landed if Actual Window Manager is enabled

RESOLVED FIXED in mozilla13

Status

()

Core
Security
--
critical
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: TinyButStrong, Assigned: khuey)

Tracking

({crash, regression})

13 Branch
mozilla13
x86_64
Windows 7
crash, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

6 years ago
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
(Reporter)

Comment 1

6 years ago
Created attachment 600119 [details]
App crash screenshot Windows 7 x64.
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
(Reporter)

Comment 3

6 years ago
Right, so what's the solution?
(Reporter)

Comment 5

6 years ago
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.
(Reporter)

Comment 7

6 years ago
Should I report the situation to ActualTools or the solution is restrict to Mozilla?

Updated

6 years ago
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.
Created attachment 600442 [details] [diff] [review]
Patch

Pathless lookups need to work for DLLs that are already loaded.
Attachment #600119 - Attachment is obsolete: true
Attachment #600442 - Flags: review?(benjamin)

Updated

6 years ago
Blocks: 730274

Comment 10

6 years ago
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)
Created attachment 601133 [details] [diff] [review]
Patch

Lets try this again.
Attachment #601133 - Flags: review?(benjamin)

Updated

6 years ago
Attachment #601133 - Flags: review?(benjamin) → review+

Updated

6 years ago
Blocks: 731846
http://hg.mozilla.org/mozilla-central/rev/3a7b9e61c263
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Blocks: 731919

Updated

6 years ago
Blocks: 732065
You need to log in before you can comment on or make changes to this bug.