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

VERIFIED FIXED in M3

Status

P1
critical
VERIFIED FIXED
20 years ago
14 years ago

People

(Reporter: mcafee, Assigned: leaf)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

20 years ago
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

20 years ago
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

20 years ago
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
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 3

20 years ago
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'?
(Reporter)

Comment 4

20 years ago
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

20 years ago
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.
(Reporter)

Updated

20 years ago
Summary: Win32: Sweetlou/apprunner Ok, mozilla.org/apprunner hosed → Win32: mozilla.org/win32/apprunner does not start
(Reporter)

Comment 6

20 years ago
resummarizing.

Updated

20 years ago
Severity: normal → critical
Priority: P3 → P1
Target Milestone: M3

Comment 7

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

Comment 8

20 years ago
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

20 years ago
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.
(Assignee)

Comment 10

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

Comment 11

20 years ago
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

20 years ago
This is working with internal builds.  mcafee, did you try rebuilding with with
Mar10 binaries?
(Reporter)

Comment 13

20 years ago
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

20 years ago
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.
(Assignee)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
(Assignee)

Comment 16

20 years ago
works for me on a win98 and winnt box.

Comment 17

20 years ago
mcafee...could you mark Verified now?

Updated

20 years ago
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.