289906 - https/ssl stops working for site when linking postscript file in <img> tag

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[mozilla.org]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319

When loading the example page the fourth time via https (http works!) Mozilla
won't load any more pages via https from that server. "Normal" http still works,
other https sites, too. Mozilla must be restarted to fix this ("Stop loading
page" does not help). Ethereal shows, that Mozilla is not even trying to reload
this page (no packets sent).

The problem is triggered by linking a postscript file via <img> ... which
Mozilla cannot display, but nethertheless it should not "lock up". ;-( The size
of the postscript file may matter. I could not reproduce it (quickly) with a
small one (20k), the one currently in the example is 115k.

Reproducible: Always

Steps to Reproduce:
1. Load https://www.informatik.uni-bremen.de/~mwiesner/moztest/index.php
2. Click on "* 1 *" (loads the page the second time)
3. Click on "* 2 *" (loads the page the third time)
4. Click on "* 3 *" (should load the fourth time but nothing happens)
(number of link does not matter, it's just for demonstration to be sure that the
page has been reloaded)
Actual Results:  
The example page does not load again. Even https://www.informatik.uni-bremen.de/
does not work either, but unencrypted
http://www.informatik.uni-bremen.de/~mwiesner/moztest/index.php still works

Expected Results:  
Load the page a fourth time. :-)

Tried both the Linux and the Windows version of 1.7.6 on two different machines.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I can confirm this....  It looks like we get confused about our persistent
connections.  Not only that, but once I've loaded the site the third time (so
clicked the second link) we leak all sorts of stuff including:

nsHttpConnection
nsHttpConnectionMgr::nsConnectionHandle
nsHttpHandler
nsHttpTransaction
nsIDNService
nsIOService
nsIOThreadPool

etc.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: HTTP log

The relevant part is, I think:

-1218106448[821e788]: nsHttpConnectionMgr::GetConnection
[ci=.Swww.informatik.uni-bremen.de:443 caps=1]
-1218106448[821e788]: nsHttpConnectionMgr::AtActiveConnectionLimit
[ci=.Swww.informatik.uni-bremen.de:443 caps=1]
-1218106448[821e788]:	 total=2, persist=2
-1218106448[821e788]:	at active connection limit!
-1218106448[821e788]:	adding transaction to pending queue [trans=b3411de8
pending-count=1]

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Leak log

Comment 4

[Boris Zbarsky [:bzbarsky]]

Note: going offline and then back online doesn't help here....

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #4)
> Note: going offline and then back online doesn't help here....

this part may be bug 286807, I think

Comment 6

[Benjamin Smedberg]

Is this postscript-image-specific? blocking- now that bug 286807 is fixed, but
we should really figure out what's going on here.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Is this postscript-image-specific? 

Probably happens any time an <img> links to something we don't support.  We
should really figure out the leaks, at least....

Comment 8

[Darin Fisher]

-> default owner

Comment 9

[Patrick McManus [:mcmanus]]

from the log you can see that the transaction is not canceled even though the channel gets onstop based on the cache throwing ILLEGAL_VALUE.. there are range requests in here too, suggesting something other than imglib is consuming that postscript stream.

anyhow, I'm going to mark this wfm.. the closest scenario I can test closes all the transactions, the new cache never throws that exception, and inspection tells me that the transaction is always cleaned up with the channel these days.