24091 - Offer Tinderbox builds to help narrow down smoketest blockers (was: Debug Builds for People that don't have Compilers)

Status: RESOLVED DUPLICATE of bug 367775

(Release Engineering :: General, enhancement, P3)

Description

[Alan S. Jones]

I have had a few odd crashes and developers have asked me if I had a debug
build.  The problem is I don't have VC6.0.  Thuse this made me ask could
Mozilla.org provide a nightly debug build like a regular nightly build is
provided.

Testers could use this to provide more detailed information to developers for
bug reports and catching errors.

I know debug builds are larger.  Thus unlike regular nightly builds that are
kept, only the latest debug would need to be kept.

May be put it at something like
pup/mozilla/nightly/latest/debug/<builds>

Some in #mozilla thought that the Win32 one could be the more important one as
not as hight a % would have a VC6.0.

[e-mail] had ideas on how this might be setup.

Comment 1

[Daniel (Leaf) Nunes]

Here's the problem... even if you have a debug build, you can't get any stack
traces without a debugger of some kind (which implies MSVC), so on windows, i'm
not sure what good this would do.

I'll leave this bug open for discussion so someone can convince me this is
important, but if i don't see anything in a couple of days, i'm going to mark
wontfix.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

It would be a useful thing for Unix builds, however, as it's easy to get gdb for
most platforms, and could improve bug-reporting there.

Comment 3

[Alan S. Jones]

I my attempts to find anything to help me provide more information on a major 
crasher I have I ran accross DebugView.  Would this be a way to provide debug 
Win32 builds?

DebugView
http://www.sysinternals.com/dbgview.htm

Short Description:
This is an Gui/device driver program that intercepts calls made to DbgPrint by 
device drivers and OutputDebugString made by Win32 programs. It allows for 
viewing and recording of debug session output, on your local machine or across 
the Internet, without an active debugger.

Comment 4

[rbs]

The additional benefit that this experimental build could provide is that it
could bundle various add-ons, e.g., MathML. Indeed, this will offer a chance 
to developpers like us to get feedback from the general public, rather than
only from the handful of "elites" who have succeeded in getting Mozilla with
the add-ons.

Comment 5

[Daniel (Leaf) Nunes]

Ok, so i'm reconsidering this... i'm still not sure that providing debugging
symbols is going to be helpful to anyone that isn't already building source, and
it'll take up more than double the space on the ftp site. 

Doing an extra build with all the options is a good idea, but requires an
additional build machine (which i might be able to scrounge up)... the problem
then becomes the lack of tinderbox coverage for this kind of build, which means
that it will break more often than not. I'm going to mark this WONTFIX, help
wanted, in case someone on the outside wants to contribute builds of this sort.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

Disk space is insanely cheap these days.  That shouldn't be a factor.  

Also, isn't the proper resolution for this REMIND, not WONTFIX?

Comment 7

[Colin Slater]

For now, Couldn't you just have a comp pull the source after a sucessfull 
Build, and have it set to build debug builds? Also, it's not like the only 
debugger is VC++, and you can get a version of VC for free, it just can't 
compile.

Comment 8

[Hixie (not reading bugmail)]

A build with all the options enabled, debug or not, would be very useful.
A debug build would also be useful, because even if you don't have a debugger,
debug mode enabled a whole bunch of new features such as visual debugging and
so on, which would be very useful for QA.

Comment 9

[Jon Granrose]

by reopening, dmose just volunteered to do this.  leaf doesn't have time, so
reassigning to dmose.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

granrose: you seem to have some sort of misunderstanding about how bugzilla is
intended to be used.  Reassigning to nobody, as I unfortunately don't have time
to work on it either, but it is a valid bug to have open.

Comment 11

[Peter Lubczynski]

Since this bug is assigned to nobody and futured, I'm changing it a bit around
to have the same fix but for a slightly different reason. Here's a copy of a
mail between mcafee and me:

Peter Lubczynski wrote:

I was wondering if the results of tinderbox builds are ever saved? In other
words, save the dist directory from each build instead of nuking it right away.
Since disk space is cheap, I'm thinking it may help daily verification if we had
these builds around, only for a few days.

mcafee:
There is code in the client/server stuff to do this, but I'm
not sure we ever got it working.  There would be a "B" that shows
up in the build square, that would be a link to the right ftp
directory.

Disk space is cheap, but running a tinderbox and keeping the space
low, periodically figuring out what to delete, and generally getting
this working takes work.  It's a good idea and not a new one, but
yeah maybe we should think about this again.  Is there a bug on this?
If not file one to me.

Disk space is cheap, but I'm not sure how we are doing on diskspace
on the ftp server for mozilla.org.  CC-ing asa re: ftp.mozilla.org
disk space availability.

-Chris

It seems like everday now we have to wait several hours for the owners of
smoketest blockers to be identified and fixed. And sometimes things get past the
smoketests only to create a bigger problem the next day. It would make it a lot
easier to narrow down who or what is responsible for causing a smoketest blocker
if we can narrow the field down to a handful of checkins instead of all the
checkins in the last 24 hours. We can then do a binary search to find out
exactly what checkin broke mail, theme switching, or whatever, without resulting
to guessing. What do you think?

---------
Looking at my debug windows build, it's about 35 megs. The Mac is a quarter of
that and the the Linux build I looked at was only 5 meg! Not using any
compression, and generously estimating one build per hour with no failures,
roughly it would take about a gig for every 24 hours of builds. I suggest we
nuke the builds after 72 hours, giving time for a weekend. If space is really a
huge concern, I'm willing to give up at least 3 gigs from one of my machines to
NFS if needed.

Comment 12

[Chris McAfee]

We need real ftp.mozilla.org disk space for this.
Yes, this is a good idea, there are other tbox ideas on
my plate too, and this is lower on the list for me.
I guess I am looking for some help here, in the mean time
maybe we can get some disk space commitment from staff.

Comment 13

[Asa Dotzler [:asa]]

Endico knows what our disk space looks like better than I do. I think it would
be extremely useful to even just provide the "latest" tinderbox build even if we
didn't keep 3 days worth around. If we can find the disk then it would be even
better to keep a day or 3 worth. 

Comment 14

[Chris McAfee]

off 098 radar

Comment 15

[Daniel de Wildt]

Is this bug still valid? 
AFAIK are tinderbox builds available.