Closed
Bug 793508
Opened 11 years ago
Closed 10 years ago
Turn Valgrind tbpl builds orange instead of red, when Valgrind reports a (runtime) error
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: gkw, Unassigned)
References
Details
(Whiteboard: [valgrind])
The Valgrind builds on tbpl should turn orange instead of red when leaks show up.
Comment 1•11 years ago
|
||
For the results to show up as orange on TBPL, the buildbot result needs to be 1:testfailed, rather than 2:busted ========= Finished 'mock_mozilla -v ...' failed (results: 2, elapsed: 54 mins, 30 secs) (at 2012-09-23 22:11:23.885714) =========
![]() |
Reporter | |
Comment 2•11 years ago
|
||
They should be orange only when leaks are found (xx bytes are definitely lost). They should still be red when there are uninitialized variables found, or invalid reads and writes. I'm not too sure about conditional jumps.
Comment 3•11 years ago
|
||
Going a few more lines up reveals: program finished with exit code 1 elapsedTime=2461.488319 ========= Finished 'mock_mozilla -v ...' failed (results: 2, elapsed: 41 mins, 6 secs) (at 2012-09-23 22:01:26.144296) ========= So, the process is exiting with the correct exit code. Looks like we need to adjust the builder object here: http://hg.mozilla.org/build/buildbotcustom/file/default/misc.py#l1510 with a mapping of process exit codes to buildbot statuses...like this: http://hg.mozilla.org/build/buildbotcustom/file/default/misc.py#l2350
Comment 4•11 years ago
|
||
(In reply to Gary Kwong [:gkw, :nth10sd] from comment #2) > They should be orange only when leaks are found (xx bytes are definitely > lost). > > They should still be red when there are uninitialized variables found, or > invalid reads and writes. > > I'm not too sure about conditional jumps. I'd rather have these all be orange, like crashes in non-Valgrind test suites. Red means "failed to build".
![]() |
Reporter | |
Comment 5•11 years ago
|
||
> I'd rather have these all be orange, like crashes in non-Valgrind test
> suites. Red means "failed to build".
Oh. You're right.
![]() |
Reporter | |
Updated•11 years ago
|
Summary: Turn Valgrind tbpl builds orange instead of red, when leaks show up → Turn Valgrind tbpl builds orange instead of red, when Valgrind issues show up
Updated•11 years ago
|
Summary: Turn Valgrind tbpl builds orange instead of red, when Valgrind issues show up → Turn Valgrind tbpl builds orange instead of red, when Valgrind reports a (runtime) error
Assignee | ||
Updated•10 years ago
|
Product: mozilla.org → Release Engineering
Comment 7•10 years ago
|
||
If we don't already have a "rewrite valgrind jobs to use mozharness" bug, that'd be a great thing to get on file (and make block this).
![]() |
Reporter | |
Comment 8•10 years ago
|
||
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #7) > If we don't already have a "rewrite valgrind jobs to use mozharness" bug, > that'd be a great thing to get on file (and make block this). Filed bug 909915.
![]() |
||
Comment 9•10 years ago
|
||
I don't think this bug is valid any more. TBPL currently marks all Valgrind runs as green regardless of success or failure, and bug 823787 is tracking that.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Assignee | ||
Updated•5 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•