Apparently we've got two different ways of building mozilla for Windows, the mozilla.org nightly apprunner is not starting for me, I get the border-only stuff. The sweetlou version does not demonstrate this behavior. Sar suggested we compare the two build environments, maybe we should make one include the other?

No, it's a function of when the pull was. They pull at different times. If I'm wrong about this, please keep the bug open. If I'm right, please close this as a non-bug.

no. I stopped seeing this on my machine early last week. The fact that we are still seeing it somewhere is interesting. It may not have anything to do with the build environment (from my builds it had more to do with the machine it was run on, not the machine it was built on) but I think we should look there first. Here is the env I build with: set BUILD_OPT=1 set CM_BLDTYPE=rel set CVSROOT=:pserver:cltbld%netscape.com@cvs.mozilla.org:/cvsroot set HOME=c:\ set HOMEDRIVE=C: set HOMEPATH=\users\default set include=d:\mssdk\include;c:\program files\devstudio\vc\include;c:\program fi les\devstudio\vc\atl\include;c:\program files\devstudio\vc\mfc\include;%include% set JAVA_HOME=c:\nstools set lib=d:\mssdk\lib;c:\program files\devstudio\vc\lib;c:\program files\devstudi o\vc\mfc\lib;%lib% set MODULAR_NETLIB=1 set MOZ_BITS=32 set MOZ_GOLD=1 set MOZ_MEDIUM=1 set MOZ_SRC=y:\ set MOZ_TOOLS=C:\nstools\ set MOZ_VCVER=42 set NGLAYOUT_PLUGINS=1 set NO_SECURITY=1 set NSPR20=1 set Path=.;C:\nstools\perl5\bin;c:\ntnfs;C:\WINNT\system32;C:\WINNT;c:\utils;c:\ cm\client\windows;c:\utils\vim;D:\fsf\emacs-19.34\bin;D:\fsf\bin;c:\program file s\devstudio\sharedide\bin\ide;c:\program files\devstudio\sharedide\bin;c:\progra m files\devstudio\vc\bin;;C:\DMI\BIN; ;c:\nstools\bin set STANDALONE_IMAGE_LIB=1 set _MSC_VER=1100

The only way to fix any disparity between the daily netscape release/verification builds and the nightly mozilla.org binaries is if i duplicate the effort that sar and donm make in testing my binaries, in addition to changing the build time from 2 am to 8 am (to match tree closures). This is not on my list of things to do. I blame the time differential for this. Should i mark this as 'invalid' or 'wontfix'?

I have seen this bug in yesterday's mozilla build as well, I don't think this is the 6-hour lag thing.

Leaf: we aren't asking you to test your binaries continously. We just want to figure out why this bug happens in your builds not in mine. it was happening in mine last week, now it's not anymore. But it's still happening in yours. Something has to be different, and it's not just time.

resummarizing.

Putting on M3 radar. These should be synced by Dogfood release.

I think this *is* a six hour lag thing, because when I pulled last night, I crashed on startup, and when I pulled later in the morning (around 11 am) the builds were just golden. People seem to be ignoring the fact that Warren was dancing all over the tree last night. The only way to prove that this is really a problem is to start both builds at the same time once, and see if you get different results.

Another way to prove this: Sarah, pull a tree from midnight at last night. Build that. Do you crash at startup? If you do, then leaf's build was correct for the date/time when he pulled.

I have a build that doesn't crash on startup on the build machine in question (for the nightlies)... is that enough proof?

If we think this is working, mark it worksforme and I will go try this again. If we don't care if the nightly build starts or not, then mark wontfix and I'll read the ftp warnings on the download page before downloading next time :-)

This is working with internal builds. mcafee, did you try rebuilding with with Mar10 binaries?

Wed March 10 mozilla-win32.zip is only a partial build, there are no binaries. Maybe we can add the smoke test for the build and only push if it passes that?

These are the results for all currently available win32 binaries: Mar11: no binaries (partial build) Mar10: no binaries (partial build) Mar9: binaries crashing on startup Mar8: nothing at all Mar7: nothing at all Mar6: nothing at all Mar5: binaries crashing on startup

I think the crashing on startup may be even beyond the machine the build is run on, but rather, what kind of mood (?? - I just don't know a better way to quantify this) that machine was in when it most recently booted. I was using the 99-03-09 mozilla.org build just fine yesterday (or maybe it was Wed., or both), but it is crashing on startup today. On the other hand, the 99-03-05 build has worked fine for me.

works for me on a win98 and winnt box.

mcafee...could you mark Verified now?