860641 - startup crash in ffi_call with RelevantKnowledge 1.0.0.2

Status: RESOLVED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Scoobidiver (away)]

I am filing it under the JavaScript component because it's a regression but it has more to do with the extension component unless it highlights other issues.
It first showed up in 23.0a1/20130410065939. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9db46ddfb517&tochange=ee5ca214e87c

It's correlated to RelevantKnowledge known as adware:
rlnx.dll 	1.3.334.8
{C7AE725D-FA5C-4027-BB4C-787EF9F8248A} 	1.0.0.2

Signature 	rlnx.dll@0x61f4 More Reports Search
UUID	8910b4fb-cd8e-4688-8868-10b0c2130411
Date Processed	2013-04-11 03:40:15
Uptime	6
Last Crash	12 seconds before submission
Install Age	21 seconds since version was first installed.
Install Time	2013-04-11 03:39:45
Product	Firefox
Version	23.0a1
Build ID	20130410065939
Release Channel	nightly
OS	Windows NT
OS Version	6.2.9200
Build Architecture	x86
Build Architecture Info	AuthenticAMD family 20 model 2 stepping 0
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x0
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x9802, AdapterSubsysID: 054a1025, AdapterDriverVersion: 8.982.0.0
D3D10 Layers? D3D10 Layers- 
Processor Notes 	sp-processor09.phx1.mozilla.com_2360:2008
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x9802
Total Virtual Memory	4294836224
Available Virtual Memory	3938074624
System Memory Use Percentage	39
Available Page File	2645966848
Available Physical Memory	2354511872

Frame 	Module 	Signature 	Source
0 	rlnx.dll 	rlnx.dll@0x61f4 	
1 	mozjs.dll 	ffi_call_win32 	
2 	mozjs.dll 	ffi_call 	js/src/ctypes/libffi/src/x86/ffi.c:299
3 	mozjs.dll 	js::ctypes::FunctionType::Call 	js/src/ctypes/CTypes.cpp:5816
4 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:401
5 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:455
6 	mozjs.dll 	js::CrossCompartmentWrapper::call 	js/src/jswrapper.cpp:486
7 	mozjs.dll 	proxy_Call 	js/src/jsproxy.cpp:3182
8 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:401
9 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2393
10 	mozjs.dll 	js::ion::CanEnterBaselineJIT 	js/src/ion/BaselineJIT.cpp:256
11 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:365
12 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:422
13 	mozjs.dll 	js::Invoke 	js/src/jsinterp.h:135
14 	mozjs.dll 	js_fun_apply 	js/src/jsfun.cpp:1032
15 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:408
16 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:455
17 	mozjs.dll 	js::CrossCompartmentWrapper::call 	js/src/jswrapper.cpp:486
18 	mozjs.dll 	proxy_Call 	js/src/jsproxy.cpp:3182
19 	mozjs.dll 	js::GetIterator 	js/src/jsiter.cpp:717
20 	mozjs.dll 	js::GuardFunApplyArgumentsOptimization 	js/src/jsinterpinlines.h:159
21 	mozglue.dll 	arena_malloc_large 	memory/mozjemalloc/jemalloc.c:4210
22 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:365
23 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:422
24 	mozjs.dll 	js::Invoke 	js/src/jsinterp.h:135
25 	mozjs.dll 	js_fun_apply 	js/src/jsfun.cpp:1032
26 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:408
27 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2393
28 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:357
29 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:422
30 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:455
31 	mozjs.dll 	js::CrossCompartmentWrapper::call 	js/src/jswrapper.cpp:486
32 	mozjs.dll 	proxy_Call 	js/src/jsproxy.cpp:3182
33 	xul.dll 	XPCWrappedNative::GetNewOrUsed 	js/xpconnect/src/XPCWrappedNative.cpp:445

More reports at:
https://crash-stats.mozilla.com/report/list?signature=rlnx.dll%400x61f4

Comment 1

[Scoobidiver (away)]

There's a similar crash with PremierOpinion (same DLL version and crash address):
pmnx.dll 	1.3.334.8

More reports at:
https://crash-stats.mozilla.com/report/list?signature=pmnx.dll%400x61f4

Comment 2

[Scoobidiver (away)]

That DLL seems shared by various malware.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=opnx.dll%400x61f4

Comment 3

[Scoobidiver (away)]

It's #1 top crasher in 23.0a2 with many duplicates.

Comment 4

[Scoobidiver (away)]

These four DLLs are all used in the RelevantKnowledge extension, {C7AE725D-FA5C-4027-BB4C-787EF9F8248A} 1.0.0.2 (see http://www.relevantknowledge.com/Home.aspx).

Comment 5

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

I just tried contacting RelevantKnowledge through their website.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

Benjamin - can you put together a patch to block those DLLs so we can try to reduce the crash rate while still on Aurora?

Comment 7

[Benjamin Smedberg]

A DLL block is pretty heavyweight if we can just use an extension block. I don't think a DLL block is the right tool here.

Comment 8

[Scoobidiver (away)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #7)
> A DLL block is pretty heavyweight if we can just use an extension block. I
> don't think a DLL block is the right tool here.
A user confirms that it doesn't crash in Safe Mode (see bp-3750c0a4-f8e4-42d4-8fd8-8bdb22130519) so the extension blocklist would be enough if RelevantKnowledge didn't fix the issue.

Comment 9

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

I've been informed by RelevantKnowledge that they're investigating the crash and they are able to reproduce the problem.

Comment 10

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

RelevantKnowledge have informed us that they have a fix ready, which will go through QA and be released towards the end of the month.

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Any update here?  We're about to go to beta and this is still hanging out at #2

Comment 12

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

They will being rolling out the update next week, shortly after the push to beta, but it'll take some time for the majority of users to be updated. We should monitor the crash reports closely in the coming weeks and decide if further action is required.

Comment 13

[Scoobidiver (away)]

(In reply to Jorge Villalobos [:jorgev] from comment #12)
> They will being rolling out the update next week
The next week is over and it still accounts for 18.6% of crashes in 23.0b1 and occurs at the same daily crash rate. Nevertheless, I see the unaffected version 1.0.0.3 showing up:
    100% (3010/3010) vs.  12% (3462/29098) {C7AE725D-FA5C-4027-BB4C-787EF9F8248A}
        100% (3000/3010) vs.  12% (3440/29098) 1.0.0.2
          0% (10/3010) vs.   0% (22/29098) 1.0.0.3

Comment 14

[Robert Kaiser]

(In reply to Scoobidiver from comment #13)
> The next week is over and it still accounts for 18.6% of crashes in 23.0b1

As comment #12 says, we expected it to be rolled out rather slowly, unfortunately. Good to see though that the new versions seems unaffected so far.

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Jorge Villalobos [:jorgev] from comment #12)
> They will being rolling out the update next week, shortly after the push to
> beta, but it'll take some time for the majority of users to be updated. We
> should monitor the crash reports closely in the coming weeks and decide if
> further action is required.

Since this is the #1 topcrash on FF23 Beta 1, let's go ahead with blocking older versions for users of 23 & up so we can ensure our users coming from FF22 (which is unaffected) don't hit this on startup of their new FF23 beta install.

Comment 16

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

The block is now live: https://addons.mozilla.org/en-US/firefox/blocked/i424

QA, please verify after giving the cache an hour or so to clear.

Comment 17

[Manuela Muntean [Away]]

I wasn't able to find RelevantKnowledge, neither from http://www.relevantknowledge.com/Home.aspx or https://addons.mozilla.org.

On https://www.relevantknowledge.com/faq.aspx I found this info:

"How did RelevantKnowledge get installed on my computer?

RelevantKnowledge research software can only be installed on your computer after receiving explicit permission from the user with the acceptance of the RelevantKnowledge User License Agreement. "

Does anyone have any thoughts/suggestions?

Comment 18

[Scoobidiver (away)]

Relevant Knowledge comes bundled with other software such as http://www.leawo.com/video-converter/free-aviconverter.html

Comment 19

[Manuela Muntean [Away]]

(In reply to Scoobidiver from comment #18)
> Relevant Knowledge comes bundled with other software such as
> http://www.leawo.com/video-converter/free-aviconverter.html

I didn't succeed to install the Relevant Knowledge add-on (there is no trace of it in the Add-ons Manager), even though the Leawo Video Converter installed properly.

Scoobidiver, do you perform some extra steps, besides installing the video converter?

Comment 20

[Manuela Muntean [Away]]

> I didn't succeed to install the Relevant Knowledge add-on (there is no trace
> of it in the Add-ons Manager), even though the Leawo Video Converter
> installed properly.

 I tried to install it on Firefox 23 beta 2, build ID: 	20130701144430

Comment 21

[Scoobidiver (away)]

(In reply to Manuela Muntean [:Manuela] [QA] from comment #19)
> Scoobidiver, do you perform some extra steps, besides installing the video
> converter?
I found the link by searching the Web. I don't install malware on my computer so I can't say. Maybe RK is now bundled with other software.

Comment 22

[Manuela Muntean [Away]]

Does anyone else know how to install Relevant Knowledge? Thanks!

Comment 23

[Robert Kaiser]

(In reply to Scoobidiver from comment #21)
> I found the link by searching the Web. I don't install malware on my
> computer so I can't say. Maybe RK is now bundled with other software.

Please don't call them "malware" unless you know they are doing actually malicious things (and crashing by itself doesn't qualify as there's a lot of software that crashes and isn't malware, including Firefox). From where we stand at this point, I'd call them "software with dubious usefulness to the user". ;-)

Comment 24

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #23)
> Please don't call them "malware" unless you know they are doing actually
> malicious things
Maybe you prefer spyware: https://www.google.com/search?q=relevant+knowledge

Comment 25

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

(In reply to Manuela Muntean [:Manuela] [QA] from comment #22)
> Does anyone else know how to install Relevant Knowledge? Thanks!

If we can't find a way to install it, we can look at the crash stats and see if there's any improvement. I'll ask the RK people and see if they can provide us with easy steps for installing.

Comment 26

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

This is what RK said:

> The easiest way to install our software is to go through www.permissionresearch.com
> and join our panel.

Comment 27

[Manuela Muntean [Away]]

Here are the crash reports from Socorro, regarding the last 28 days:

1) for the first signature, [@ rlnx.dll@0x61f4], there are many crashes on: 25.0a1 and 24.0a2, and already 14 crashes reported on 23.0b2

https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&reason_type=contains&date=2013-07-03&range_value=28&range_unit=days&hang_type=any&process_type=any&signature=rlnx.dll%400x61f4

2) for the second signature, [@ pmnx.dll@0x61f4], there are many crashes on 25.0a1, a few on 24.0a2 and 1 crash on 23.0b2

https://crash-stats.mozilla.com/report/list?signature=pmnx.dll%400x61f4&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-07-03+06%3A00%3A00&range_value=4

3) for the 3rd signature, [@ opnx.dll@0x61f4], there are only 2 crashes on 25.0a1

https://crash-stats.mozilla.com/report/list?signature=opnx.dll%400x61f4&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-07-03+06%3A00%3A00&range_value=4

4) for the 4th signature, [@ prnx.dll@0x61f4], most crashes regard only 23.0b1 and 23.0a2

https://crash-stats.mozilla.com/report/list?signature=prnx.dll%400x61f4&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-07-03+06%3A00%3A00&range_value=4

Overall, things seem to get better, but 2 out of 4 signatures are still appearing in the crash reports.

Comment 28

[Robert Kaiser]

Starting with 23.0b4 (and Nightly/Aurora builds from tomorrow on), the in-build blocklist has the block for versions up to 1.0.0.2 - as this is a startup crash, most people won't be able to update a blocklist from within the running build, so we probably will need to see the background update service moving them to those newer versions that have the add-on blocked right from the start (or, of course, for the add-on being updated to 1.0.0.3).

Comment 29

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #28)
> Starting with 23.0b4 (and Nightly/Aurora builds from tomorrow on), the
> in-build blocklist has the block for versions up to 1.0.0.2
Unfortunately the blocklist doesn't work (see https://crash-stats.mozilla.com/report/list?signature=rlnx.dll%400x61f4&product=Firefox&version=Firefox%3A23.0b4) maybe because there's a race condition between the new XML file in Program Files and the old one in the profile. Another explanation would be that the RK extension is loaded before the blocklist. We should wait 23.0b5 with two identical XML files or rely on the RK update process.

Comment 30

[Benjamin Smedberg]

The app-distributed blocklist is only used for new users who don't have a profile. Updating the app blocklist is not going to help any existing user on upgrade.

Comment 31

[Scoobidiver (away)]

It's fixed from the RK side with RK extension 1.0.0.3 and from the Mozilla side with a blocklist pushed to prod 5 weeks before the release of 23.0, enough time for the blocklist to be deployed to almost all the current Release population.

Comment 32

[Robert Kaiser]

(In reply to Scoobidiver from comment #31)
> It's fixed from the RK side with RK extension 1.0.0.3 and from the Mozilla
> side with a blocklist pushed to prod 5 weeks before the release of 23.0,
> enough time for the blocklist to be deployed to almost all the current
> Release population.

Unless you can prove it's not a topcrash for current versions any more, I disagree with marking it fixed.

Sorry. I'd be the first person to cheer when we can consider this fixed, but it's #2 on all of 23.0b4, and last-3-days-by-build of 24.0a2 and 25.0a1, and I see it not dropping off the topcrashes any time soon, so IMHO we need to keep it open.

Comment 33

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #32)
> Unless you can prove it's not a topcrash for current versions any more, I
> disagree with marking it fixed.
It's not fixed for those who stay on channels blocklisted after its beginning (23.0 Beta, Aurora 24 and 25.0a1), can't update the blocklist and haven't updated RK. But it's fixed for 23.0 Release, 24.0 Release and 25.0 Release because of the 5-week latency to update the blocklist in that channel.
The tracking and status flags are for Release not other channels.

Comment 34

[Robert Kaiser]

The is no 5-week latency. Apparently the profile blocklist always take precedence over the built-in blocklist in the current implementation and therefore all people that already have an installation need to either delete their profile or start in safe mode and get the blocklist updated. This is unfortunate, not sure how or if we can fix that.

Comment 35

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #34)
> The is no 5-week latency.
Not every people open Firefox everyday so the Release population has five weeks to launch it once and for a session that lasts long enough for the blocklist update.

Comment 36

[u279076]

Dropping qawanted since there's nothing actionable for QA at this point.

Comment 37

[Lukas Blakk [:lsblakk] use ?needinfo]

If this is not going to impact release users and it is veritably dropping off since the updated version has shipped I think we can call this fixed.  Can we trust that people with FF23beta1-3 will either re-install or eventually be updated to most recent RelevantKnowledge within the week (since by their timeline they should have unthrottled the update to 100% around now)?

Comment 38

[Robert Kaiser]

(In reply to [e-mail] [:lsblakk] from comment #37)
> Can we trust that people with FF23beta1-3 will either re-install or
> eventually be updated to most recent RelevantKnowledge within the week
> (since by their timeline they should have unthrottled the update to 100%
> around now)?

I don't think we can trust what will happen, we can only trust the data we're seeing. I don't feel comfortable with calling this fixed unless we actually see it dropping significantly in beta.

Comment 39

[Benjamin Smedberg]

So the status of this bug is:

* We deployed a blocklist item:
** This should help any release-channel user who has used Firefox since 1-July.
* On the beta channel, users are already crashing at/near startup so their blocklist will never be updated
** For beta users, the only way we have to fix this is for relevantknowledge to update them
* There is no further technical action we can take (without significantly rearchitecting the blocklist service).

Since there are no further actions, I don't think there's a point in leaving this bug open. We should of course continue to watch it.

Comment 40

[Robert Kaiser]

Well, in theory, we could make blocklists installed with a product update take precedent over profile blocklists if the date of the in-product one is newer and therefore have the block still take effect. Not sure if that's something to do on beta, though.

Comment 41

[Benjamin Smedberg]

It is not. Dates are probably also a bad idea, and if we're going to do that it should use explicit versioning, which requires additional server support.

Comment 42

[Lukas Blakk [:lsblakk] use ?needinfo]

We'll be shipping with a blocklist for all older versions of Relevant Knowledge since their update that no longer crashes is not necessarily going to be deployed to 100% uptake yet when we release.

Jorge can you get the blocklist updated for FF23 release?

Comment 43

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

The block is already set for 23 and above. It doesn't make a difference which channel a version is on.

Comment 44

[Scoobidiver (away)]

Unfortunately, there are crashes in 23.0 Release so the add-on blocklist doesn't prevent the DLL from loading.
For SUMO, the solution is to upgrade to the latest version of Relevant Knowledge or whatever its name (Premier Onion).

Comment 45

[[:Cww]]

is there no way to uninstall the DLL without starting firefox?

Comment 46

[Scoobidiver (away)]

(In reply to [:Cww] from comment #45)
> is there no way to uninstall the DLL without starting firefox?
See http://www.relevantknowledge.com/faq.aspx?#Section7 for manually uninstalling.
For a DLL blocking in Firefox, we had failed DLL blocklisting for similar DLLs in the past because of the way it was loaded. In addition, it should be hard coded and can't use the downloaded add-on blocklist.

Comment 47

[Robert Kaiser]

Correlations still show that it's happening with the older version (this is from last week and 23.0, released at that time):

  rlnx.dll@0x61f4|EXCEPTION_ACCESS_VIOLATION_READ (1900 crashes)
    100% (1900/1900) vs.   6% (2325/41674) {C7AE725D-FA5C-4027-BB4C-787EF9F8248A}
        100% (1900/1900) vs.   6% (2295/41674) 1.0.0.2
          0% (0/1900) vs.   0% (30/41674) 1.0.0.3

Current correlations on the dll level also show this being located with one specific DLL version:

100% (2827/2827) vs.   5% (2866/57000) rlnx.dll
0% (13/2827) vs.   0% (13/57000) 1.3.334.8
100% (2814/2827) vs.   5% (2829/57000) 1.3.334.9
0% (0/2827) vs.   0% (24/57000) 1.3.336.2

What just came up in my mind as the add-on blocklist isn't really effective there - couldn't we do in-code DLL blocklisting there for the affected DLLs and versions of this so that we can mitigate this for release (say, for a 23.0.1)?

This issue is in the same ballpark as the Radeon issue in 23.0 release, but this is actually at startup. :(

Comment 48

[(no longer active)]

I would be happy to write a DLL blocklist fix for this.  Two questions though:

1) What is the *exact* version range that needs to be blocked?
2) Can somebody reproduce this so that they can verify the fix?

(Needinfo'ing myself so that I don't forget about it)

Comment 49

[Scoobidiver (away)]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #48)
> I would be happy to write a DLL blocklist fix for this.  Two questions
> though:
> 1) What is the *exact* version range that needs to be blocked?
See bug 904001 which is the bug for the DLL blocklist.

> 2) Can somebody reproduce this so that they can verify the fix?
This old version of RK is no longer available so the fix can't be verified except by crash stats. It's just a shot in the dark.

Comment 50

[Lukas Blakk [:lsblakk] use ?needinfo]

QA - see comment 26 for another way to try and install.

Comment 51

[Lukas Blakk [:lsblakk] use ?needinfo]

Ehsan - It is a shot in the dark but anything you can do to try and block according to bug 904001 we would like to try and land this on mozilla-release today as well in order to try and ship this in our 23.0.1

Please get in touch in IRC if you have more questions so we can keep moving forward on this in a timely fashion.

Comment 52

[(no longer active)]

(In reply to [e-mail] [:lsblakk] from comment #51)
> Ehsan - It is a shot in the dark but anything you can do to try and block
> according to bug 904001 we would like to try and land this on
> mozilla-release today as well in order to try and ship this in our 23.0.1
> 
> Please get in touch in IRC if you have more questions so we can keep moving
> forward on this in a timely fashion.

Sure, will do.  Looking into this right now.

Comment 53

[u279076]

(In reply to [e-mail] [:lsblakk] from comment #50)
> QA - see comment 26 for another way to try and install.

The final step of the sign-up process prompts me to install an the "Permission Research Download Support" add-on. This add-on is a restartless add-on. Upon installation I have the following in about:support::Extensions

> Add-on: PermissionResearch Download Support
> Version: 1.0.1
> ID: PRd1-72IMa9XjxezONw@jetpack

I can't seem to find any trace of "RelevantKnowledge 1.0.0.2" on my system, nor any of the previously indicated DLLs (rlnx.dll, pmnx.dll, opnx.dll, prnx.dll). I also have not experienced any startup crashes.

Comment 54

[u279076]

Some additional info, I checked with Process Explorer and I did find the following:

> wininit.exe
>> services.exe
>>> prservice.exe (owned by PermissionResearch)
>>>> prmrsr.exe (owned by PermissionResearch)
> firefox.exe (with prls.dll loaded)
> prmrsr.exe (owned by PermissionResearch)

I hope this information is useful.

Comment 55

[u279076]

Further info, upon restart I was offered a second add-on, PermissionResearch 1.0.0.3. Upon allowing this add-on to install I have the following in about:support :: Extensions:

> PermissionResearch	            
> 1.0.0.3
> {C7AE725D-FA5C-4027-BB4C-787EF9F8248A}
>
> PermissionResearch Download Support	
> 1.0.1
> PRd1-72IMa9XjxezONw@jetpack

However, I'm still only seeing prls.dll attached to firefox.exe; none of the DLLs from comment 27 are found on my system. I'm also not reproducing any startup crashes.

Comment 56

[(no longer active)]

What is the version of prls.dll?

Comment 57

[u279076]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #56)
> What is the version of prls.dll?

4.0.17.31

Comment 58

[Robert Kaiser]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #55)
> Further info, upon restart I was offered a second add-on, PermissionResearch
> 1.0.0.3. Upon allowing this add-on to install I have the following in
> about:support :: Extensions:
> 
> > PermissionResearch	            
> > 1.0.0.3
> > {C7AE725D-FA5C-4027-BB4C-787EF9F8248A}

That's the add-on we're talking about here, yes. The 1.0.0.3 version seems to be fixed and not crash any more, though, the DLLs with 1.0.0.2 are the issue.

Comment 59

[Scoobidiver (away)]

There are no crashes in 24.0a2/20130814 so far that contains the fix of bug 904001.

Comment 60

[(no longer active)]

(In reply to comment #59)
> There are no crashes in 24.0a2/20130814 so far that contains the fix of bug
> 904001.

That's great news!

Comment 61

[Robert Kaiser]

I guess Scoobidiver means 25.0a2 actually. ;-)

That said, from what I can see, neither Nightly 26 nor Aurora 25 are showing any of those crashes in builds from the 14th or newer, so I think the DLL blocklist actually worked.

Thanks a lot for the fast reaction, Ehsan!

Comment 62

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

Seems like this was fixed by bug 904001. Please reopen if this is not the case.