Closed Bug 1338170 Opened 3 years ago Closed 3 years ago

Crash in @0x0 | ffi_call [Internet Download Manager]

Categories

(Toolkit :: Blocklist Policy Requests, defect, critical)

x86
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1333486
Tracking Status
firefox51 --- wontfix
firefox52 --- wontfix
firefox53 - fix-optional
firefox54 --- fix-optional

People

(Reporter: marcia, Unassigned)

Details

(Keywords: crash, topcrash-win, topcrash+)

This bug was filed from the Socorro interface and is 
report bp-83ec03f2-db85-4f61-866a-6e3762170209.
=============================================================

Filing this since it is a pretty high (#6 top browser crash) in the Aurora crash data: http://bit.ly/2kw1QtW.

100.0% in signature vs 00.69% overall) Addon "Internet Download Manager integration" = true
Ctypes-usage crash in IDM. Jorge/kev: blocklist?
Flags: needinfo?(kev)
Flags: needinfo?(jorge)
I'll block it on 53 and above, per our policy on loading binaries.
Component: Other → Blocklisting
Flags: needinfo?(kev)
Flags: needinfo?(jorge)
Product: External Software Affecting Firefox → Toolkit
Depends on: 1338832
this signature is the top crasher in early stability data for 53.0b1.
Since releasing beta 1 there are about 600 crashes on 200 instances. Our blocking either didn't work or the IDM version may have shifted. The reports I looked at all have Internet Download Manager 6.23.17. Jorge, can we blocklist that version?
Flags: needinfo?(jorge)
this issue amounts to 13.3% of all browser crashes on 53.0b1 last week.
The block from bug 1338832 covers versions 0 - 6.26.11, starting with Firefox 53.0a1. It could be that these users have the blocklist disabled or decided to enable the add-on anyway.

Kamil, can you verify that the block in bug 1338832 is working correctly?
Flags: needinfo?(jorge) → needinfo?(kjozwiak)
Tracking since this is a persistent top crash.
(In reply to Jorge Villalobos [:jorgev] from comment #6)
> Kamil, can you verify that the block in bug 1338832 is working correctly?

When I initially launch fx53.0b2 with IDM installed (IDM.6.26.Build.9), the add-on is completely disabled with no way of re-enabling it via about:addons. The following message is displayed:

"IDM integration is incompatible with Firefox 53.0"

I managed to disable the compatibility check via "extensions.checkCompatibility.53.0;false" and re-enabled the add-on which required a restart. Once the browser is restarted, you'll run into the crash every single time FX attempts to launch. The only way to recover is to keep crashing until you can either restart into safe browsing and disable IDM or by selecting "Refresh FX".

When the add-on is disabled (can't keep it enabled) and the compatibility check is disabled, pinging the blocklist server will output the following:

* Blocklist state for mozilla_cc2@internetdownloadmanager.com changed from 1 to 1

As stated above, I can't really test the block with IDM enabled as FX gets into a state where it crashes whenever FX is launched making it impossible to test.

Jorge, the only thing that might be an issue is that the block appears to be a "soft" block [1][2]. Not sure if this is because the add-on is disabled when I'm pinging the server?

Platforms used:

* Win 10 Pro x64 & Win 8.1 x64

Crashes:

* bp-3b12989a-b24a-4f43-a5c0-74e842170314
* bp-290daee0-59c7-4c8f-a217-4b5182170314

[1] Blocklist state for mozilla_cc2@internetdownloadmanager.com changed from 1 to 1
[2] https://dxr.mozilla.org/mozilla-central/source/xpcom/system/nsIBlocklistService.idl#19
Flags: needinfo?(kjozwiak) → needinfo?(jorge)
Soft blocking is the default type of block we use for non-malicious add-ons. The only difference is that users are able to re-enable the blocked add-on. It's possible that overriding the compatibility for the add-on is also taken as overriding the softblock. I'll try changing the block to a hard block to see if that makes a difference.
Flags: needinfo?(jorge)
(In reply to Jorge Villalobos [:jorgev] from comment #10)
> I'll try changing the block to a hard block to see if that makes a difference.

Let me know once this is live and I'll double check and make sure it's using a hard block rather than the soft block. Other than that, is there anything else that I can do here?
The hard block is now live. Please give it another try.
Flags: needinfo?(kjozwiak)
(In reply to Jorge Villalobos [:jorgev] from comment #12)
> The hard block is now live. Please give it another try.
I'm now getting the following output when pinging the block server indicating that the IDM add-on should be blocked and never used:

* Blocklist state for mozilla_cc2@internetdownloadmanager.com changed from 1 to 2

Even with the compatibility check disabled via "extensions.checkCompatibility.53.0;false", there's no way of enabling the affected IDM add-on with the current block, unless you disable blocklisting via about:config which will result in FX crashing on startup.

Platforms Used:

* Win 10 Pro x64 - PASSED (correctly being blocked)
* Win 8.1 x64 - PASSED (correctly being blocked)
* Win 7 Pro x64 - PASSED (correctly being blocked)
Flags: needinfo?(kjozwiak)
That's good. However, given this is a startup crash, this probably won't help affected users until they are updated to a new beta with the updated block in the baked-in blocklist. ni Liz just so she's aware.
Flags: needinfo?(lhenry)
If it's a startup crash they might never get the chance to update. I'm seeing 5000 crashes from 1700 installations so far from 53 beta 1. Is the "baked in blocklist" there now for future betas or would it be there once we release?
Flags: needinfo?(lhenry)
I thought the updater ran in a separate process and would still work if Firefox crashed at startup.

> Is the "baked in blocklist" there now for future betas or would it be there once we release?

As I understand it, Firefox is always built with the latest set of blocks, so the next beta should include this one.
(In reply to Jorge Villalobos [:jorgev] from comment #16)
> I thought the updater ran in a separate process and would still work if
> Firefox crashed at startup.

I think the problem is that Firefox will not be able to download the update at all, if it crashes on startup.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1333486
No longer blocks: win64-rollout
Crash Signature: [@ @0x0 | ffi_call]
No longer depends on: 1338832
Component: Blocklist Policy Requests → Blocklist Implementation
Component: Blocklist Implementation → Blocklist Policy Requests
You need to log in before you can comment on or make changes to this bug.