Closed Bug 77640 Opened 23 years ago Closed 16 years ago
Setup tinderbox machine for Boehm leak tests
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.
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.
Summary: Setup tinderbox machine for special test builds and test results → Setup tinderbox machine for Boehm leak tests
Target Milestone: --- → mozilla0.9.1
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 +).
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.
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?
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
nav triage team: Does this really need the mozilla0.9.1 milestone? How about something further out like mozilla1.0 or Future?
not critical for 0.9.1 but we definitely would take the data if we can get it. moving target milestone.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
mcafee and curt, keep going on trying to get this hooked up...
nav triage team: Marking nsbeta1-, p3, and mozilla1.0 to get off triage radar. Chris just get to this when you can.
Priority: -- → P3
Target Milestone: mozilla0.9.2 → mozilla1.0
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.
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.
Assignee: mcafee → curt
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → Future
Let's get this into a component that will WONTFIX it.
Assignee: curt → nobody
Component: Embedding: GTK Widget → Build & Release
Product: Core → mozilla.org
QA Contact: pavlov → build
Target Milestone: Future → ---
Version: Trunk → other
Way, way, way out-of-date. We have BloatTest and BloatTest2 in tinderbox now.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.