This hasn't affected builds on Tinderbox yet, but I think we're also not sure whether any clobber builds have happened there that could have been affected by this. So, I used the clobberer tool to force clobbers on our Android builders, which should take effect in this cset: https://tbpl.mozilla.org/?rev=8ffdb4c7404a
According to various folks testing tinderbox and local builds, this seems to affect debug builds only. Maybe related to bug 683127?
(In reply to Matt Brubeck (:mbrubeck) from comment #2) > Maybe related to bug 683127? I doubt it. The parts that landed only affect the zip reading (not even the decompression part, just parsing zip headers and getting the compressed stream), not the linker itself.
the crash I saw we were reading in an invalid length. Mike, can you locally back out your change and do a debug build?
I get a lot of different crashes on debug builds, depending on what i do, and even just quitting triggers a crash. I tested on d85920b5691b, and then backed out bug 683127 completely (still crashed) and for good measure, I also backed out bug 712579 (still crashed)
I believe this is the same as bug 717336 that I filed yesterday. Will dupe that to here. I isolated it to somewhere between 011e3cef6068 and c42d08fdec34.
From bug 717336: (In reply to James Willcox (:snorp) (firstname.lastname@example.org) from comment #6) > I have an updated range: > > e79ef0ffcb09 is good > 2f310f456107 is bad
In another form: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e79ef0ffcb09&tochange=2f310f456107
https://hg.mozilla.org/integration/mozilla-inbound/rev/88acaad9c766 This should fix it
Is it fixed?
Works for me now.
I''m still crashing with my own debug build shortly after startup, I've filed bug 719985 for it.