43029 - browser crashes on startup

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Philipp O. Meissner]

Source: 2000-06-18 tarball

Even if profile-directory and mozregistry.dat are deleted mozilla crashes on 
startup. I've got this problem (same to my collegues) since several 
source-releases.
At the same time the 2000-06-18-21 binary works fine and stable.

The messages in the debug-window:

nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
ProfileManager : CreateNewProfile
Profile Name: default
Profile Dir: E:\mozilla\M17\2000-06-18\mozilla\dist\WIN32_D.OBJ\Users50
ProfileName : default
ProfileDir  : E:\mozilla\M17\2000-06-18\mozilla\dist\WIN32_D.OBJ\Users50\default
WEBSHELL+ = 1
plugins at: D:\Programme\Netscape\Communicator\Program\Plugins
plugins at: E:\mozilla\M17\2000-06-18\mozilla\dist\WIN32_D.OBJ\bin\plugins
Initialized app shell component {18c2f989-b09f-11d2-bcde-00805f0e1353}, 
rv=0x00000000
WEBSHELL+ = 2
CSSLoaderImpl::LoadAgentSheet: Load of URL 
'file:///E|/mozilla/M17/2000-06-18/mozilla/dist/WIN32_D.OBJ/Users50/default/chro
me/user.css' failed.  Error code: 18
Obtained name of Personal Toolbar from bookmarks string bundle.
Start reading in bookmarks.html
Finished reading in bookmarks.html  (70000 microseconds)
Enabling Quirk StyleSheet
Note: verifyreflow is disabled
Note: styleverifytree is disabled
Note: frameverifytree is disabled
Enabling Quirk StyleSheet
CSSLoaderImpl::DidLoadStyle: Load of URL 'chrome://communicator/skin/menu.css' 
failed.  Error code: 16389
WEBSHELL+ = 3
Enabling Quirk StyleSheet
Enabling Quirk StyleSheet

Comment 1

[Doron Rosenberg (IBM)]

did you delete the previous mozilla version as well?

Does the file mozilla/M17/2000-06-18/mozilla/dist/WIN32_D.OBJ/Users50/default/chro
me/user.css exist?

ccing leaf - leaf, do you know anything about this?

Comment 2

[Daniel (Leaf) Nunes]

Hmm... this could be a windows2k thing v. a windows NT thing. Some people are
complaining about menu.css being missing from their debug builds on m16 as well,
but it works for me on NT. If you touch 
bin\chrome\skins\modern\communicator\skin\menu.css (make an empty file)

your build should work again.

Comment 3

[timeless]

I'm confirming this bug and moving it to build config.
Touching the missing file worked for an m16 build (leaf edburns and I discussed 
this in #mozilla).  The file itself in the non debug builds (eg win32 talkback) 
is 0 bytes.

Comment 4

[Philipp O. Meissner]

touching bin\chrome\skins\modern\communicator\skin\menu.css indeed solves the 
problem and the build works.

Comment 5

[Philipp O. Meissner]

This is a winzip-bug! Winzip doesn't extract files of 0 byte of size under 
certain circumstances: winzip extracts xyz_tar.gzip to xyz.tar into a temp-dir 
and opens  xyz.tar to extract it - and doesn't touch any 0-byte-files.
On the other side it extracts 0-byte-files from "single" archives like 
mozilla-win32.zip as one should expect.
A warning should be added to the "Common Sticking Points" at 
http://www.mozilla.org/build/win32.html.

Comment 6

[timeless]

I didn't see this w/ winzip8 on windows2000 using the files i will attach as 
test cases.

Comment 7

[timeless]

Attachment: Null testcase #1 0bytes.txt .tar .gz

Comment 8

[timeless]

Attachment: Test File #2 0bytes.txt.tar

Comment 9

[Philipp O. Meissner]

Forget my previous comment. WinZip (release 7.0 SR-1 (1285)) generally refuses 
to extract 0-byte-files from tar-files (same works fine with winzip-archives - 
that's the reason why the binaries worked)

Both of your testcases failed on my machine: no file 0Bytes.txt has 
been extracted, no err-msg occurred. I tried "selected files", "all files" and 
"files: 0Bytes.txt". 

Comment 10

[Daniel (Leaf) Nunes]

This is absolutely something that can be release-noted while i get a source .zip
file up.

The workaround of touching the file works, or, to make sure no more zero length
css files are missing, use tar and gunzip to get the source out.

I'll get a zip of the source posted shortly.

Comment 11

[leger]

Adding crash keyword

Comment 12

[Michael Hore]

I'm on x86 linux and having a similar problem
mozilla was working very well until I accidentally forkbombed myself (grin)..
I've tried removing .mozilla and package and reinstalling, and it hasn't worked,
I've tried M17 and the Sep 5 nightly..
Here's the output from the ./mozilla script
./run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.
     LIBRARY_PATH=.
       SHLIB_PATH=.
          LIBPATH=.
       ADDON_PATH=.
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
WEBSHELL+ = 1
CSSLoaderImpl::LoadAgentSheet: Load of URL
'file:///home/helmet/.mozilla/default/chrome/userChrome.css' failed.  Error
code: 16389
CSSLoaderImpl::LoadAgentSheet: Load of URL
'file:///home/helmet/.mozilla/default/chrome/userContent.css' failed.  Error
code: 16389
WEBSHELL+ = 2

then it dumps me back to the shell
I've had a few different outputs mentioning user.css, menu.css and various
things too, this one's from the nightly

Comment 13

[Michael Hore]

Strike that from the record.. the catalyst for the problem is a security update
of the libc from my vendor (redhat) so the problem I am having would be redhat
specific. bug 51482 if at all interested

Comment 14

[edburns]

I don't see this on win32 now.

Comment 15

[Jon Granrose]

sounds like this is fixed.  marking resolved/fixed based on edburns comment
above so this falls off the untriaged crasher radar.

Comment 16

[John Unruh]

Verified fixed.