592125 - Blocklist IDM CC 7.1.1 and 7.1.2 for nightlies and beta 5

Status: RESOLVED INVALID

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Shawn Wilsher :sdwilsh]

It's causing a number of crashes (see blocked bugs) and should be disabled.  Neither of these versions are available on AMO.

We might just want to bump the max version that we blocked in bug 578443.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Will need to do this PDQ; should be a quick and easy fix.

Charles: we altered a few more interfaces, which is where you seem to be causing crashes. Please see bug 591678 and bug 591880 for more information.

Comment 2

[Ryan Doherty (:rdoherty)]

(In reply to comment #0)
> We might just want to bump the max version that we blocked in bug 578443.

wfm

Comment 3

[Michael Morgan [:morgamic]]

Attachment: v1, increases max to blitem range

Run this in an IT ticket if rstrong +r's it:
update blitems set max = '7.1.2' where guid='[e-mail]' and max = '6.9.8'

Comment 4

[[e-mail]]

Frankly I think we should consider blocklisting all versions, and then reset 'max' if they get things working.

If this is a result of binary changes on our end, then they're clearly not recompiling, and they need to fix that before we unblock them. If it's not a result of binary changes, then they're still doing something wrong, and they need to fix that before we unblock them. These problems have been there a while now...

Comment 5

[Michael Morgan [:morgamic]]

I'm cool with what you guys want to do.

Comment 6

[[e-mail]]

Doublechecking the timing, it's possible this was a result of the nsIChannel change. We'll know tomorrow, since the fix is in tonight's nightly. Should we blocklist before then or wait?

Comment 7

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

(In reply to comment #4)
> Frankly I think we should consider blocklisting all versions, and then reset
> 'max' if they get things working.

Blocklisting all versions should be the last option. IDM is used by a ton of people that paid for it, and previous blocks have been a big problem.

Comment 8

[Michael Morgan [:morgamic]]

Okay, so figure out what's causing it and we can block it tomorrow if we still need to.

Comment 9

[Ken]

FWIW: I am still using 6.9.9 (mentioned in bug https://bugzilla.mozilla.org/show_bug.cgi?id=578443 ) with the latest nightlies and it still works.
So blocklisting all versions might be overkill? I am not sure I do not have access (or have the URL) listing crashes by version of the IDM CC .xpi file.

Current nightly version I'm using:
Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100830 Firefox/4.0b5pre Firefox/4.0b5pre ID:20100830040705

Comment 10

[[e-mail]]

One users' experience doesn't scale to our nightly population; the fact that we're seeing a lot of crashes is the only relevant fact.

If this is the result of binary changes, it's unfortunate we don't have a better system for handling them. (This is somewhat of a new problem for us, given Gecko 2.0!) At the least, we'll want to reach out to them the next time we make changes (i.e. Fx5) and get a new version released, then block all older versions on trunk.

Comment 11

[Ken]

(In reply to comment #10)
> One users' experience doesn't scale to our nightly population; the fact that
> we're seeing a lot of crashes is the only relevant fact.
> 
So the crash stats show 6.9.9 is causing a lot of crashes also? 
I saw on the forums some were using a beta version of the 6.9.9 add-on, and when I tried the version they said they were using I got an insta-crash.

Comment 12

[chris hofmann]

(In reply to comment #11)
> (In reply to comment #10)
> > One users' experience doesn't scale to our nightly population; the fact that
> > we're seeing a lot of crashes is the only relevant fact.
> > 
> So the crash stats show 6.9.9 is causing a lot of crashes also? 
> I saw on the forums some were using a beta version of the 6.9.9 add-on, and
> when I tried the version they said they were using I got an insta-crash.

there is a lower volume crash with these signatures that have been around for awhile.  The data shows a few users hitting that still.

I think in this bug we are trying to solve the 100 nsObserverService crashes per day, and the 50 RunnableMethod crashes per day that are happening on 4.0b5 pre builds from the 28th.  (4.0b5pre 20100828040640)


count signature release build (from crash data on aug 28)

   4 @0x0 | nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 4.0b5pre 20100828040640
   4 PL_DHashTableOperate | nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 4.0b5pre 20100828040640
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.5.11 20100701023340
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.5.5 20091102152451
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.6.6 20100625231939
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.6.8 20100722155716
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 4.0b4 20100818132640
 107 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 4.0b5pre 20100828040640


count signature release build (from crash data on aug 29)

   1 @0x0 | nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.6.8 20100722155716
   6 @0x0 | nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 4.0b5pre 20100828040640
   3 PL_DHashTableOperate | nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 4.0b5pre 20100828040640
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.1b3 20090304233338
   4 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.6.8 20100722155716
  89 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 4.0b5pre 20100828040640

can you link to the form post that you saw?

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Thanks for the analysis, Chris, though I think it belongs in the source bugs themselves. We have decent evidence that IDM 7.1 and 7.2 are causing crashes, and if that evidence vanishes after the fix for the UUID, we'll close this bug as INVALID, otherwise we'll blocklist. I don't want to lose your analysis, but I think this is one treatment we're planning on using for the symptoms we're seeing, not the only one.

Comment 14

[chris hofmann]

see https://bugzilla.mozilla.org/show_bug.cgi?id=591879#c11 for similar ramp up on RunnableMethod<mozilla::ipc::SyncChannel crashes on 4.0b5pre at about the same time.

Comment 15

[Shawn Wilsher :sdwilsh]

(In reply to comment #13)
> Thanks for the analysis, Chris, though I think it belongs in the source bugs
> themselves. We have decent evidence that IDM 7.1 and 7.2 are causing crashes,
> and if that evidence vanishes after the fix for the UUID, we'll close this bug
> as INVALID, otherwise we'll blocklist. I don't want to lose your analysis, but
> I think this is one treatment we're planning on using for the symptoms we're
> seeing, not the only one.
Note that that is 7.1.1 and 7.1.2.

Comment 16

[[e-mail]]

This looks fixed by the 20100831 nightly, so I think we're good here. We'll likely have to deal with this again in the near future, but we can worry about it then.

I take it we're not worried about users still on the affected nightlies, right?

Comment 17

[Michael Morgan [:morgamic]]

Okay - thanks for following up dwitte.