77640 - Setup tinderbox machine for Boehm leak tests

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P3)

Description

[Curt Patrick (gone)]

The machine I'm doing these builds on now is called sweetums.  I guess this will 
be the right machine to set up as a tinderbox build machine.

The tinderbox reports need to report both when a build has failed and what the 
results are of tests done against builds which succeed.

Currently I'm build with the script /u/curt/boehm/scripts/build/build_boehm.csh.  
Build results end up in the file /u/curt/boehm/cm/mozilla/out.

Currently I'm running the tests with the script 
/u/curt/boehm/scripts/test/launch_boehm_test.csh.  All the output gets 
redirected to various log files which are turned into reports and graphs.

I can have the test results output the following string:  
"BoehmTestResults,<leak_count_number>,<leak_amount_number>".  I'm not sure where 
in the process this string needs to be generated, and currently all standard out 
and stderr is getting pumped into logfiles so you'll need to tell me what needs 
to change in that department.

BTW, once we get this working for the leak test we'll need to do the same thing 
for reflow builds/tests--I guess on the same machine?

One last thought.  Chofmann says that we should identify these as experimental 
for the time being, i.e., we don't want the tree to get closed when these builds 
fail but we do want to eyes on the problems.

Comment 1

[Chris McAfee]

Shorter summary, marking 091 since waterson/curt need this soon.

A given tinderbox can run any number of tests.  If the tests take
a long time, we might think about spreading the duty over
two machines.

We can start with MozillaTest and move over to SeaMonkey once
this is working.

Comment 2

[Curt Patrick (gone)]

On sweetums, the build itself takes about 5 hrs, but then I'm actually building 
across nfs, and doing two builds simultaneously, because speed hasn't really 
been an issue.

The tests take about 3 hours to run.  (Reflow tests will add another hour +).

Comment 3

[chris hofmann]

lets get things up and running on sweetums, then transfer over
in a couple of weeks when the first of the new 1.5 ghz systems
show up.

Comment 4

[Chris McAfee]

sweetums is running a generic test tinderbox:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaTest

What configure options do we need to have a boehm-enabled build?
Does it need to be optimized?

Comment 5

[Curt Patrick (gone)]

Here is what I'm building with:

ac_add_options --enable-debug
ac_add_options --disable-tests
ac_add_options --enable-cpp-rtti
ac_add_options --enable-boehm

Comment 6

[Paul Chen]

nav triage team:

Does this really need the mozilla0.9.1 milestone? How about something further out 
like mozilla1.0 or Future?

Comment 7

[chris hofmann]

not critical for 0.9.1 but we definitely would take the data if we can get it.
moving target milestone.

Comment 8

[chris hofmann]

mcafee and curt, keep going on trying to get this hooked up...

Comment 9

[Paul Chen]

nav triage team:

Marking nsbeta1-, p3, and mozilla1.0 to get off triage radar. Chris just get to 
this when you can.

Comment 10

[Chris McAfee]

tried this build again, again it crashes on startup.
I think we should set up a tinderbox with this config
and fix this before going after the server-side change.
This is easy to do, I think the setup is already done
for sweetums.

Comment 11

[Chris McAfee]

over to curt.  if/when this test is working, I can add the server-side changes.
I need something working in order to test the server.

Comment 12

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 13

[Vedran Miletic]

retargeting

Comment 14

[Samuel Sidler (old account; do not CC)]

Let's get this into a component that will WONTFIX it.

Comment 15

[Chris Cooper [:coop] (he/him)]

Way, way, way out-of-date. We have BloatTest and BloatTest2 in tinderbox now.