Closed Bug 456159 Opened 16 years ago Closed 16 years ago

Add tracemonkey tinderbox for debug builds

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: gal, Unassigned)

Details

It would be nice to have tinderbox builds with debug enabled. Its almost impossible to debug JIT regressions without debug information and the disassembly output. With debug builds we can redirect users to capture some additional information with the debug builds when they file bugs.
The consensus was that we want to have debug builds for mozilla-central, but we won't set up debug tinderboxes for the tracemonkey tree. We will try to push changes into mozilla-central often and early to benefit from the debug builds there.
So we don't have this for m-c either, and I think these have been WONTFIXed in the past. I think the right solution here will be to finish bug 420474 (and a mac counterpart for it, which I have a partial patch for somewhere), and just get debug symbols for our nightly builds on the symbol server.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
The issue isn't just symbols, it's assertions being enabled. Is there a new plan (I had an old one, blogged four years ago, dbaron made it happen on one tinderbox) to make assertions fatal?

/be
Ah, that I can't speak to. If that's what you're after, you can reopen this bug (although it's probably a dupe of some other older bug) or find out about fatal assertions.
David, Jesse: see comment 3 and comment 4. Is there a bug tracking assertion-enabled continuous builds, and/or (in case there is, but it's better to focus on tracemonkey with this bug) should this bug be reopened?

/be
See the dependencies of bug 279923?
Note that in bug 372581 we got tinderboxes building debug and running the unit test suites on 1.9, but they were perma-orange and RelEng couldn't find any interested parties to work on fixing the assertions and leaks to make them green. RelEng is understandably not interested in doing the work to port those machines to building 1.9.1 unless there's platform buy in to make them usable. I suspect that having assertion-free and leak-free runs of TUnit/mochitest/reftest would get us most of the way to enabling fatal assertions by default.
What about the idea of having a tinderbox that displays an assertion *count* on the waterfall so we can actually get the number down?
For Tracemonkey, we also have useful diagnostic stuff compiled DEBUG-only, like the TRACEMONKEY=verbose LIR and assembly dumps, and abort data.  Would be quite helpful for people to be able to run a test case and produce that data for us.  (Quite helpful in the "will let us develop a fair bit faster" sense.)
Is there any reason that stuff needs to be debug-only, aside from codesize? Could you just turn it on for nightlies? (even conditionally, so that it's on for tracemonkey builds but not m-c builds)
Code size and non-zero codegen-time performance impact.
You are, of course, welcome to reopen this bug. I don't know that RelEng has resources to make it happen in the short term, but it does sound like you have a valid use case.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.