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)
Tracking
()
RESOLVED
FIXED
mozilla13
People
(Reporter: tinybutstrong, Assigned: khuey)
References
Details
(Keywords: crash, regression)
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
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•13 years ago
|
||
Updated•13 years ago
|
Blocks: 728429
Severity: normal → critical
Component: Untriaged → Security
Keywords: regression
Product: Firefox → Core
QA Contact: untriaged → toolkit
Target Milestone: --- → mozilla13
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•13 years ago
|
||
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•13 years ago
|
||
Right, so what's the solution?
Assignee | ||
Comment 4•13 years ago
|
||
I'm not sure yet.
Reporter | ||
Comment 5•13 years ago
|
||
Can you back the bug 728429 until a solution is found?
Assignee | ||
Comment 6•13 years ago
|
||
No. If this is a problem you can downgrade to Aurora until this is fixed.
Reporter | ||
Comment 7•13 years ago
|
||
Should I report the situation to ActualTools or the solution is restrict to Mozilla?
Assignee | ||
Comment 8•13 years ago
|
||
(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.
Assignee | ||
Comment 9•13 years ago
|
||
Pathless lookups need to work for DLLs that are already loaded.
Attachment #600119 -
Attachment is obsolete: true
Attachment #600442 -
Flags: review?(benjamin)
Comment 10•13 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...
Assignee | ||
Comment 11•13 years ago
|
||
(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.
Assignee | ||
Updated•13 years ago
|
Attachment #600442 -
Attachment is obsolete: true
Attachment #600442 -
Flags: review?(benjamin)
Assignee | ||
Comment 12•13 years ago
|
||
Lets try this again.
Attachment #601133 -
Flags: review?(benjamin)
Updated•13 years ago
|
Attachment #601133 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 13•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•