1162263 - Hazard build failures are ignored

Status: RESOLVED FIXED

(Core :: JavaScript: GC, defect)

Description

[Steve Fink [:sfink] [:s:]]

I just noticed that there are some errors in the hazard build. That should have caused the job to fail, but it was succeeding and reporting 0 hazards.

And it's bad. Because Ehsan semi-recently landed something that causes *lots* of compiles to fail. So the hazard analysis was only reporting problems in a subset of the build, opening up the possibility of more hazards getting introduced.

And they did. I've been working on getting the analysis running locally, and when it finally did, I was very surprised to see it report a number of different hazards.

The root problem here is that sixgill is intentionally forgiving of build failures that are due to the plugin -- it tries to compile with the plugin enabled, and if that fails, it retries with the plugin disabled and exits with this second compile's error code.

Or, in short, AAAAAAAAAAAAAAAAAAAAAAARRRRRRRUUUUUUUUUGGGGGGGGGHHHHHHHHH!!!!!!!!!!!!

I believe sixgill's behavior is probably reasonable for its original use, which was to handle large complex code bases as best it could without needing to handle implement 100% of C++. It is most certainly not the best behavior for something we rely on to prevent security flaws (even though we still aren't *really* handling 100% of the C++ in Gecko, but the missing bits so far haven't been much of an issue.)

Comment 1

[Andrew McCreight [:mccr8]]

Any progress on this, Steve? We've had at least one regression since this was file.

Comment 2

[Steve Fink [:sfink] [:s:]]

(In reply to Andrew McCreight [:mccr8] from comment #1)
> Any progress on this, Steve? We've had at least one regression since this
> was file.

I fixed the breakage from Ehsan's bug, so we had coverage for a while. My rebuilt sixgill package worked fine (and fixed this problem) for the browser build, but was mysteriously failing on the b2g build. I never did get that figured out.

I'm looking into this again now, given bug 1171059. I may at least push the browser fix live. Then we'd only be exposed for b2g-specific breakage. But I can't do that until we either make the code compatible with gcc 4.7 (which I'm guessing is what the problem is now), or I update gcc to 4.9. I've tested that locally, but the in-tree gcc build script doesn't handle gcc 4.9. So I may have to do something like take the regular gcc tooltool package we're using, graft in the parts I need, rebuild sixgill with that, and then stop using a hazard-specific gcc. That would be much better, if it works.

Comment 3

[Steve Fink [:sfink] [:s:]]

Attachment: Switch browser hazard builds to gcc 4.9.1

I'm going to upgrade just the browser hazard build to gcc 4.9.1, since the b2g stuff is still causing me some issues. The sixgill in this patch also contains the fix to error out on any plugin failure instead of continuing on with a non-plugin build. (Note that it will still do the non-plugin build, just to see if that fixes the problem, but it will use the return status code from the plugin build.)

Comment 4

[Steve Fink [:sfink] [:s:]]

Attachment: Do not allow plugin to silently fail

Ok, this bug looks to be the most appropriate for this fix. Though I thought there was another bug that I had already attached it to. Tough to track these things when sixgill is not in-tree.

Comment 5

[Steve Fink [:sfink] [:s:]]

I should really put sixgill in a more visible repo somewhere. The fix here landed 3 years ago.

http://hg.mozilla.org/users/sfink_mozilla.com/sixgill/rev/fea6aeaace06