3550 - Win32: mozilla.org/win32/apprunner does not start

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[Chris McAfee]

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?

Comment 1

[Chris Yeh]

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.

Comment 2

[sar]

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:[e-mail]:/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

Comment 3

[Daniel (Leaf) Nunes]

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'?

Comment 4

[Chris McAfee]

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

Comment 5

[sar]

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.

Comment 6

[Chris McAfee]

resummarizing.

Comment 7

[leger]

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

Comment 8

[Chris Yeh]

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.

Comment 9

[Chris Yeh]

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.

Comment 10

[Daniel (Leaf) Nunes]

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

Comment 11

[Chris McAfee]

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 :-)

Comment 12

[leger]

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

Comment 13

[Chris McAfee]

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?

Comment 14

[edwin]

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

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 16

[Daniel (Leaf) Nunes]

works for me on a win98 and winnt box.

Comment 17

[leger]

mcafee...could you mark Verified now?