From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; 0.8.1) BuildID: 2001032208 the tgz version of this build crashes when loading any URL. The installer-version works fine. Reproducible: Always Steps to Reproduce: 1. get the TGZ-version 2. load an URL from your bookmark list Actual Results: browser crashes Expected Results: browser should not crash When I run mozilla normally, I get the following message: Program received signal SIGSEGV, Segmentation fault. 0x4028a6e8 in free () at malloc.c:2952 2952 malloc.c: Datei oder Verzeichnis nicht gefunden. After exporting MALLOC_CHECK_=2 I get Program received signal SIGABRT, Aborted. 0x40257a71 in __kill () from /lib/libc.so.6 sadly I am unable to provide a better traceback, but the normal Linux version does not come with talkback, and the installer version with talk back works fine. The debugger sadly don't like this problem either.

for me 2001032109 (or 08?) does work fine, but the 2001032205 build does crash every time.

i have had a similar problem with my CVS build for the past 12 hours, but mozilla-i386-pc-linux-gnu-sea.tar.gz 2001032205 is fine. Backtrace follows.

forgot to set severity... Sorry for spam

Stack dies off in necko cache. Reassigning.

Reassigning to darin. Bumping severity to blocker. A browser without bookmarks? *cringe*

here it doesn't only affect bookmarks. It crashes regardless of clickin a bookmark, fill in an URL and hit enter, or click button on personal taskbar. Gotta add: I upgraded to XFree86 4.0.2 yesterday. The first moz-build after that ran well. When i later made a clean build new cache was checked in and enabled in the meanwhile. Those later builds crash.

I have a 3.3.x version of Xfree, so this should not be the reason. Anyway, if it is the cache, why does it crash with the TGZ, but not with the other builds? Where do they differ?

I've seen this stack trace on the mac before. Not sure what it going on.

My take on this is that the disk cache is not being careful when reading its meta data. A file is probably corrupt (or non-existent). Try blowing away your cache directory, and see if that helps. [the new cache uses a different directory than the old cache (since they both live side-by-side for the moment). look in ~/.mozilla/<your-profile>/<salt>/ for a directory called NewCache.]

I'm unable to reproduce this problem in my Linux debug build.

wiped NewCache dir clean and now it runs fine on first run, bookmarks and all. In the NewCache dir were files from the 17th when i tried the experimental build from ftp.mozilla.org. I visit much the same sites each day - various news-sites, mozilla, bugzilla etc.

Even though I'm not able to reproduce this bug reliably, I do see how the disk cache can be made more reliable. It currently reads the header size from the meta data file and in a debug build it would ASSERT if the header size does not match the expected size. In an optimized build, however, this check is not done. If mHeaderSize is larger than sizeof(MetaDataHeader) then mKey could have a bogus value, which would explain the crash while calling free(). I'll write up a patch to fix this.

Ahh.. then this definitely explains the problem!! The assertion needs to be a real runtime check... and we should definitely printf the message. It should not be a DEBUG only check!!

turns out "delete disk cache" from prefs doesn't work.

Hmm... I filed a separate bug 73062 for the 'clear disk cache' pref not working.

Gagan is working on a fix to temporarily disable the disk cache until a better fix can be found (for the crashing part when going from old->new or new->old). Once that fix is in, we'll downgrade this bug to not be a smoketest blocker.

Just spoke to Patrick and I think this bug would only show up with people who have been 'playing' with the new cache before it landed yesterday. So I think its reasonable to downgrade it to not be a smoketest blocker and continue to get the right fix in. Removing smoketest keyword.

not sure it's so intuitive that cache directory changed name. Perhaps the warning should indicate dir-name..

-> beard

Fix checked in.