673002 - Analyze binary add-ons from addons.mozilla.org

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Dave Herman gave me a big tarball with all the addons. The high-level breakdown in as follows:

  Valid: 9129, non-zip: 56, corrupted: 20, binary: 51

This means that out of 9129 addons, 51 are binary (0.56%). I looked at all the Linux and Windows binaries, and it looks like none of them use JSAPI! To make sure I didn't make a mistake, I did the same analysis on the Kikin addon, which is not on AMO and which is known to use JSAPI. It does indeed import a bunch of JSAPI entry points.

I'll post more detailed results here. Also, I have a zip file with all the binaries extracted if anyone wants to examine them.

Comment 1

[David Mandelin [:dmandelin]]

Good to hear. It sounds like for the most part when we change JSAPI we just need to put out the word ahead of time on m.d.t.js-engine and the AMO channels.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: script to find binary addons

This is the script I used to process all the addons. The first argument is a path to the directory containing all the addons. The second argument is a fresh directory where it will put all the dlls it finds.

It turns out that a bunch of them are messed up, so most of the code deals with that. For some reason some of the .xpi files actually contain HTML. Also, some of the zip files are reported as corrupted by unzip. I skipped over all these, although the ones in the latter category could probably be recovered.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: output of Python script

This is the output of the analysis script. It just shows which xpi files were skipped. Note that some of them have references in their chrome manifest to files that don't exist. Mostly this seems to happen when a Mac addon claims to have a .dll or a .so, but it really only has a .dylib. Or some variation of that.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: list of symbols imported by each addon

This is the result of dumpbin.exe -IMPORTS foo.dll (thanks khuey). As can be seen, mozjs.dll does not appear.

I also ran a Windows version of strings on each dll and grepped for service names, of the form "@xyz;1". A lot of addons used some sort of xpcom proxying service, which seems to have something to do with threads. One addon (cooliris) wanted the XPCOM context stack service. I don't know enough to say if this matters. I can upload the list of anyone is interested. (I left it on my Windows partition by accident.)

Comment 5

[Dave Herman [:dherman]]

9129 seems small to me -- I thought there were somewhere between 15k and 20k addons. Also, the XPI's that contained HTML might possibly be the result of a failed wget in Wil Clouser's script that collected all the addons from AMO.

CC'ing Wil and Matt Basta, who does the AMO validator. Wil & Matt: do you think this suggests that the tarball might not be good? Could you guys help Bill and me make sure we can get an accurate snapshot of the full set of AMO addons?

Thanks,
Dave

Comment 6

[Matt Basta [:basta]]

I'll run this through our stats tool, Grizwald, and get back to you tomorrow.

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Another odd thing is that, out of ~12,000 directories in the tarball, only about 9,000 have xpi files in them.

Comment 8

[Matt Basta [:basta]]

Themes are packaged in JAR files. That might account for the other chunk.

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

The failed wget seems quite possible. How can we figure that out?

Comment 10

[Wil Clouser [:clouserw]]

There is no wget.  I ran the script on a box with the add-ons on an NFS mount.  The script is super simple, it just makes a best guess on what the latest file is and copies it:  http://pastebin.mozilla.org/1282356

Comment 11

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I'm going to mark this as FIXED, I guess, since the work is done.