873904 - Linux32 Valgrind builds broken by Linux32-on-64 builds

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Phil Ringnalda (:philor)]

In theory http://mxr.mozilla.org/mozilla-central/source/browser/config/mozconfigs/linux32/valgrind#1 -> http://mxr.mozilla.org/mozilla-central/source/browser/config/mozconfigs/linux32/nightly#10 would have 32-bit Valgrind builds sourcing the mozconfig that would let them do 32-on-64, but that theory falls down when it meets http://mxr.mozilla.org/build/source/tools/scripts/valgrind/valgrind.sh#66 - as you can see from https://tbpl.mozilla.org/php/getParsedLog.php?id=23130466&full=1&branch=mozilla-central for a 32-bit build on a 64-bit slave, we wind up using the linux64/valgrind mozconfig.

Comment 1

[Mike Hommey [:glandium]]

(In reply to Phil Ringnalda (:philor) from comment #0)
> http://mxr.mozilla.org/build/source/tools/scripts/valgrind/valgrind.sh#66 -

Urgh, why doesn't it use the same thing as other builds?

Comment 3

[Phil Ringnalda (:philor)]

Not that I think you really wanted an answer, certainly not the answer that exists, but it's different (as are Jetpack-on-the-jetpack-tree and SpiderMonkey shell builds) because creating a new pure-buildbot job was a pain in the ass, requiring a ton of boilerplate and reconfig after reconfig, and mozharness was still in the far future, so they did several of these ScriptFactory jobs, where all buildbot does is set a few variables and run a shell script or a Python script that does everything else. None of those are sexy things that releng feels any ownership of, so if anyone else wants to rewrite the way they work, patches are (sort of) welcome, but they aren't going to do it.

Comment 4

[Phil Ringnalda (:philor)]

So, just stop pretending we can run it? Three months of just wasting machine time now.

Comment 5

[Ed Morley [:emorley]]

John, you've indicated wanting to know when something is being run broken for some time - these jobs (Valgrind x86; the 64bit variant is fine) now fall into this category. Please can you make a call on this either way? (ie: allocate someone from releng to tweak the mozconfigs per comment 0, or else allocate someone to turn these off). Thanks! :-)

https://tbpl.mozilla.org/?showall=1&jobname=valgrind
https://tbpl.mozilla.org/php/getParsedLog.php?id=26530880&tree=Mozilla-Central#error0

Comment 6

[Phil Ringnalda (:philor)]

Attachment: [configs] stop it

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Are we sure this is the right thing to do in the long run?

Perhaps it's a suitable stop-gap, but stopping tests just because of a harness issue doesn't seem to be appropriate, although keeping a test harness continuously red isn't appropriate either. :-/

Comment 8

[Ed Morley [:emorley]]

Maybe get your manager to hassle releng? I was hoping the needinfo on joduinn might get somewhere, but it doesn't seem to have helped... :-(

Comment 9

[Phil Ringnalda (:philor)]

Comment on attachment 798682 [details] [diff] [review]
[configs] stop it

https://hg.mozilla.org/build/buildbot-configs/rev/a8709aa9d223

Comment 10

[Nick Thomas [:nthomas] (UTC+12)]

In production

Comment 11

[Ed Morley [:emorley]]

GCing now redundant, but unanswered requests.

Comment 12

[Phil Ringnalda (:philor)]

This would be FIXED if when you loaded https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-searchStr=valgrind there were Linux32 jobs showing as well as Linux64.