39241 - Moz crashes with segfault after downloading compressed files over HTTP

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Jeffrey Baker]

On i686-pc-linux-gnu Build 2000051308, Mozilla exits with a segmentation fault
while downloading a gzip compressed file.  Moz doesn't crash when downloading
files it doesn't know how to decompress (e.g. bzip2).  To reproduce:

1) Start Moz
2) Go to http://www.quakeforge.net/files.php (wait)
3) Download quakeforge-0.1.1.tar.gz (wait)

Result: Segmentation fault

This does not happen if you download the bzipped version of the same file, and
it also does not happen if you download gzipped files via ftp (e.g. mozilla
nightlies).  Note also that the file seems to be downloaded correctly and
completely each time I tried.  Moz dumps core after the download is done.

This might be related to Bug 33808, and general download horkage.

Comment 1

[Eliot Landrum]

WORKSFORME on 2000052508, Linux. I tested with a small file
(http://eliot.landrum.cx/mozilla/test.tar.gz), the file downloaded fine and I
was able to continue browsing. I don't have a fat pipe, so I don't want to test
on a bigger file like that quakeforge tarball.

Reporter, can you retry on a recent build with the small file I created? Please
report back.

Comment 2

[Jeffrey Baker]

You are right, this bug is gone in 2000052508.  Buth your testcase and my
testcase work without crashing.  Download is still broken in many ways, but
marking this one as WORKSFORME.

Comment 3

[Asa Dotzler [:asa]]

Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

Comment 4

[Doron Rosenberg (IBM)]

verified

Comment 5

[Jeffrey Baker]

Back from the dead.  Use original procedure to reproduce on Linux, build
2000060908.

Comment 6

[Asa Dotzler [:asa]]

over to Networking for investigation.

Comment 7

[Andreas Franke (gone)]

Attachment: stack trace from a 6/2 build

Comment 8

[Andreas Franke (gone)]

This seems to be an infinite recursion in nsReplacementPolicy:

#55181 0x408ee947 in nsReplacementPolicy::AddAllRecordsInCache ()
#55182 0x408ef501 in nsReplacementPolicy::LoadAllRecordsInAllCacheDatabases ()
#55183 0x408ef3cb in nsReplacementPolicy::DeleteOneEntry ()
#55184 0x408ef0df in nsReplacementPolicy::CheckForTooManyCacheEntries ()
#55185 0x408ef1e6 in nsReplacementPolicy::AssociateCacheEntryWithRecord ()
#55186 0x408ee947 in nsReplacementPolicy::AddAllRecordsInCache ()
#55187 0x408ef501 in nsReplacementPolicy::LoadAllRecordsInAllCacheDatabases ()
#55188 0x408ef555 in nsReplacementPolicy::Evict ()
#55189 0x408eba05 in nsCacheManager::LimitDiskCacheSize ()
#55190 0x408eba25 in nsCacheManager::LimitCacheSize ()
#55191 0x408eff2b in CacheOutputStream::Write ()
#55192 0x408edeaf in InterceptStreamListener::write ()
#55193 0x408edf00 in InterceptStreamListener::Read ()
#55194 0x4142456d in nsStreamXferOp::OnDataAvailable ()

Comment 9

[Gagan]

->neeti

Comment 10

[neeti]

I downloaded quakeforge-0.1.1.tar.gz (wait)on 6/28 linux build, I am not able to 
reproduce the problem.

Neeti

Comment 11

[Gagan]

This might also have gone since I added the option of switching off automagic 
gunzip'ng which was skewing off download/progress data and hence the cache 
problems. I would safely mark it fixed now and let someone reopen it if they see 
it. 

Comment 12

[Tom Everingham]

works for me too.

verified:
Linux 2000062808