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

Status: RESOLVED DUPLICATE of bug 1333486

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Marcia Knous [:marcia]]

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

Comment 1

[Benjamin Smedberg]

Ctypes-usage crash in IDM. Jorge/kev: blocklist?

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

I'll block it on 53 and above, per our policy on loading binaries.

Comment 3

[[:philipp]]

this signature is the top crasher in early stability data for 53.0b1.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

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?

Comment 5

[[:philipp]]

this issue amounts to 13.3% of all browser crashes on 53.0b1 last week.

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

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?

Comment 7

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

TOP1 crasher on Firefox 53

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking since this is a persistent top crash.

Comment 9

[Kamil Jozwiak [:kjozwiak]]

(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 [e-mail] 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 [e-mail] changed from 1 to 1
[2] https://dxr.mozilla.org/mozilla-central/source/xpcom/system/nsIBlocklistService.idl#19

Comment 10

[Jorge Villalobos [:jorgev] (he/him)]

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.

Comment 11

[Kamil Jozwiak [:kjozwiak]]

(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?

Comment 12

[Jorge Villalobos [:jorgev] (he/him)]

The hard block is now live. Please give it another try.

Comment 13

[Kamil Jozwiak [: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 [e-mail] 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)

Comment 14

[Jorge Villalobos [:jorgev] (he/him)]

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.

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

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?

Comment 16

[Jorge Villalobos [:jorgev] (he/him)]

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.

Comment 17

[Marco Castelluccio [:marco]]

(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.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking in the duplicate bug.