148758 - saving the page prevents further downloads from server [leaks file descriptor]

Status: VERIFIED WORKSFORME

(Core :: Networking, defect, P1)

Description

[Michal 'hramrach' Suchanek]

2002-05-30-05 Mac OS X 10.1.4
If I 
- go to bug 148361, 
- save the page as complete html and 
- try go back to the page on server 

I get: 
/show_bug.cgi?id=148361 cannot be found, check the name ...

-tried twice
-restarting browser helps
-other bugs are shown correctly

Comment 1

[Adrian Ulrich]

wfm 2002060123 linux

Comment 2

[Michal 'hramrach' Suchanek]

Doesn't work with 2002-06-02-03

Comment 3

[Greg K.]

hramrach, what do you mean by "try go back to the page on server?" Do you mean
reload the page?

Comment 4

[Michal 'hramrach' Suchanek]

I tried several things that gave the same result:
-reloading the page
-typing the url
-typing the bug# into the bug# field on bottom of a bugzilla page

Comment 5

[Greg K.]

Confirmed using FizzillaCFM/2002052305 (RC3). Reloading the URL fails after
saving as HTML.

I'm not really sure what Component's at fault here. Raising Severity to major.

Comment 6

[benc]

+cc neeti: putting bug on fasttrack to engineering.

Comment 7

[neeti]

This wfm on win2000. I do not have access to a Mac to test this out. However I
get  the following assertions on win2k

Document http://www.mozilla.org/start/ loaded successfully
warning: property cp1256 already exists
Document http://bugzilla.mozilla.org/show_bug.cgi?id=148361 loaded successfully
Error reading file jar:resource:///chrome/classic.jar!/skin/classic/global/menu/
menu-arrow-hover.gif
Error reading file jar:resource:///chrome/classic.jar!/skin/classic/global/menu/
menu-arrow-hover.gif
spec=/show_bug.cgi
WARNING: malformed url: no scheme, file d:\tip\mozilla\netwerk\base\src\nsStanda
rdURL.cpp, line 727
spec=/show_bug.cgi
WARNING: malformed url: no scheme, file d:\tip\mozilla\netwerk\base\src\nsStanda
rdURL.cpp, line 727
WEBSHELL+ = 5
WARNING: Cannot tell if file:///C:/download/show_bug.cgi.html is a directory or
file, file d:\tip\mozilla\netwerk\base\src\nsIOServiceWin.cpp, line 84
WARNING: Cannot tell if file:///C:/download/show_bug.cgi_files is a directory or
 file, file d:\tip\mozilla\netwerk\base\src\nsIOServiceWin.cpp, line 84
WARNING: Cannot tell if file:///C:/download/show_bug.cgi_files/mozilla-banner.gi
f is a directory or file, file d:\tip\mozilla\netwerk\base\src\nsIOServiceWin.cp
p, line 84
Error reading fiWARNING: Cannot tell if file:///C:/download/show_bug.cgi_files/m
ozilla-16.png is a directory or file, file d:\tip\mozilla\netwerk\base\src\nsIOS
erviceWin.cpp, line 84
le C:\Documents and Settings\neeti.JUKEBOX\Application Data\Mozilla\Profiles\tes
t\vj1xq2ng.slt\Cache\6D###!!! ASSERTION: uninitialized: 'mHost.mLen >= 0', file
d:\tip\mozilla\netwerk\base\src\nsStandardURL.cpp, line 1120
6081A4d01
###!!! ASSERTION: uninitialized: 'mHost.mLen >= 0', file d:\tip\mozilla\netwerk\
base\src\nsStandardURL.cpp, line 1120
WEBSHELL- = 4

Comment 8

[Tom Everingham]

Attachment: http log of transactions up to the error

Comment 9

[Darin Fisher]

this sounds a lot like bug 149090 which was fixed on the trunk last week and
just fixed on the 1.0 branch yesterday.

Comment 10

[Tom Everingham]

Yes it does sound similar but I think this is a different bug or a variation of
it.  Bug 149090 was easily reproducable by displaying an image and pressing
back/fwd a few times.  It is now gone.  This one, you display the page, hit
save, then shift-reload the page and get the error just about every time.  

The log file is from yesterdays branch build but this is also reproducable on
todays trunk (2002061208). So far I'm only seeing on the mac osX, but I haven't
checked os9 yet.

Comment 11

[Darin Fisher]

-> me

tever: thx for checking today's trunk build!

Comment 12

[Darin Fisher]

OK, so this kind of error typically corresponds to a leaked file descriptor. 
under MacOS, the result is the "not found" error dialog.  under linux i observed
an open file descriptor under /proc/xxxxx/fd/ referencing a file in the cache.

Comment 13

[Darin Fisher]

-> 1.2alpha since i won't have any time to work on this now that i'm on vacation...

or... dougt, you have time to investigate this one?

Comment 14

[Darin Fisher]

i'm no longer able to reproduce this bug (trunk linux 2002083005)... using the
technique of observing the open filedescriptors under /proc/<pid/fd.  this may
have been fixed by the recent landing of the disk cache streams patch (bug 81724).

marking WORKSFORME

Comment 15

[benc]

reporter: can you see if this is happening with a recent build?

Comment 16

[Michal 'hramrach' Suchanek]

With 1.1 it works for me as well.