Closed Bug 35150 Opened 25 years ago Closed 25 years ago

tcp streams not closing?

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: spam, Assigned: ruslan)

References

Details

Attachments

(1 file)

some observations of difference in socket behaviour under NC4.7 and Moz (and some worthless thoughts around it)
4.03 KB, text/plain
Details
From Bugzilla Helper: User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.5-15 i586) BuildID: 2000040708 wondered about bug 33952 (mouseclicks on links don't work) and went to a "problem site" where i've had to click from 5 to 10 times last week to get anywhere. Suspecting this has to do with back/forward not working too. First i had been to mozilla.org, ftp.mozilla.org, counter.li.org and others. CLicked on links to test at http://www.digi.no - a site with various commercial banners also. - nested some 4 levels. (used "story-links" reading "Les mer her" Did a "netstat" under linux and saw many tcp connections still listed. Saw that i had to click from 5 to 10 times before anything happened. For each click there was a few brief flashes in the modem but mostly nothing happened apart from that. Then went to a site without banners - a clean little normal homesite. Did a "netstat" This showed up - and remained there! tcp 0 0 mp-217-221-127.dax:2450 popq.c2i.net:pop-3 TIME_WAIT tcp 1 0 mp-217-221-127.dax:2448 home.c2i.net:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2443 ads-digi3.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2442 ads-digi1.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2441 ads-digi3.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2440 ads-digi5.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2439 ads-digi5.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2438 ads-digi1.sol.no:www CLOSE_WAIT tcp 0 332 mp-217-221-127.dax:2436 195.204.29.42:www CLOSE tcp 0 0 mp-217-221-127.dax:2434 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-1:codasrv-se ads-digi1.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.:codasrv ads-digi4.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.da:venus ads-digi1.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2429 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2428 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 332 mp-217-221-127.dax:2426 195.204.29.42:www CLOSE tcp 0 0 mp-217-221-127.dax:2424 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2423 ads-digi1.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2422 ads-digi3.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2421 ads-digi5.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2420 ads-digi5.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2419 ads-digi1.sol.no:www CLOSE_WAIT tcp 0 338 mp-217-221-127.dax:2417 195.204.29.42:www CLOSE tcp 0 0 mp-217-221-127.dax:2416 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2415 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2414 ads-digi3.sol.no:www CLOSE_WAIT tcp 0 338 mp-217-221-127.dax:2413 195.204.29.42:www CLOSE tcp 0 338 mp-217-221-127.dax:2411 195.204.29.42:www CLOSE tcp 0 0 mp-217-221-127.dax:2409 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2408 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2407 ads-digi3.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2406 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2404 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2403 ads-digi5.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2402 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 345 mp-217-221-1:cvspserver 195.204.29.42:www CLOSE tcp 0 345 mp-217-221-127.dax:2399 195.204.29.42:www CLOSE tcp 0 0 mp-217-221-127.dax:2396 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2395 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2394 ads-digi5.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2393 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2392 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2391 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2390 ads-digi2.sol.no:www CLOSE_WAIT tcp 52544 0 mp-217-221-127.dax:2386 h-207-200-73-39.n:37917 ESTABLISHED tcp 1 0 mp-217-221-127.dax:2366 aleph.counter.li.or:www CLOSE_WAIT tcp 57 0 mp-217-221-127.dax:2281 h-207-200-73-39.net:ftp CLOSE_WAIT Reproducible: Always Steps to Reproduce: 1.see above. 2. 3. Actual Results: see above. Expected Results: well...nothing like this.
tested again with gdb running: went to these sites, URL's filled in manually. Whever an enter doesn't trigger the url, give an enter and try again. http://www.digi.no click a link there till it triggers go to: http://www.computerworld.no click a link till it triggers go to: http://www.sol.no click linkt till it triggers go to http://www.itavisen.no here it froze or crashed with this message: Document http://www.itavisen.no/ loaded successfully Document: Done (19.991 secs) Program received signal SIGWINCH, Window size changed. [Switching to Thread 5457] Program received signal SIGWINCH, Window size changed. 0x40393a00 in __poll (fds=0xbf7ffd00, nfds=1, timeout=12384) at ../sysdeps/unix/sysv/linux/poll.c:45 ../sysdeps/unix/sysv/linux/poll.c:45: No such file or directory. (gdb) -- I had not changed windowsize, only focus to and back from a terminal window to see what was going on since it seemed to hang. backtrace: (gdb) bt #0 0x40393a00 in __poll (fds=0xbf7ffd00, nfds=1, timeout=12384) at ../sysdeps/unix/sysv/linux/poll.c:45 #1 0x40165724 in PR_Poll () #2 0x4084dd65 in NSGetModule () #3 0x4010847f in nsThread::Main () #4 0x4016678e in PR_Select () #5 0x4017db25 in pthread_start_thread (arg=0xbf7ffe40) at manager.c:241 Also did a netstat before terminating: Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 1 0 mp-217-221-127.dax:2825 h-207-200-73-38.net:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2805 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2804 ads-digi5.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2803 ads-digi1.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2802 ads-digi1.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2801 ads-digi2.sol.no:www CLOSE_WAIT tcp 1 0 mp-217-221-127.dax:2799 195.204.29.42:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2797 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2796 ads-digi3.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2795 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2794 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2793 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 346 mp-217-221-127.dax:2791 195.204.29.42:www CLOSE tcp 1 0 mp-217-221-127.dax:2788 ads-digi5.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2787 ads-digi4.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2786 ads-digi1.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2785 ads-digi1.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2784 ads-digi3.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2783 ads-digi1.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2782 ads-digi3.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2781 ads-digi2.sol.no:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2778 212.71.67.227:www CLOSE tcp 0 0 mp-217-221-127.dax:2776 212.71.67.227:www CLOSE tcp 0 0 mp-217-221-127.dax:2775 212.71.67.227:www CLOSE tcp 0 0 mp-217-221-127.dax:2769 212.71.67.227:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2768 212.71.67.227:www CLOSE tcp 0 0 mp-217-221-127.dax:2766 212.71.67.227:www CLOSE tcp 0 0 mp-217-221-127.dax:2765 212.71.67.227:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2761 194.237.107.21:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2760 194.237.107.21:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2754 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2753 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2752 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2750 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2749 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2748 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2746 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2745 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2744 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2743 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2742 web2.computerworld.:www CLOSE_WAIT tcp 0 0 mp-217-221-127.dax:2740 web2.computerworld.:www CLOSE_WAIT
tried the same journey again - crash didn't reproduce so in the same session i started "walking" the same route once more and noticed that when the url's now don't load, the statusfield still updates, but NOT with the URL i typed in the entry field, but with the link to one of the banners. Sample: Typed in http://www.digi.no again, and Moz went nowhere, but the statusfield refreshed and suddenly displayed the URL of the first banner on the page.
the summary is misleading...it's the listening to those sockets that never ceise - oughtn't some forced timeout at least happen? These are stale sockets.
tried adding user_pref("network.http.version", "1.0"); in prefs.js but this seems to make things even worse network-wise, even if it makes the browser move on first click. Do test the sites in 35150 succesively. After each load (linux) do a "netstat |grep tcp |wc -l" Finish the walk off with a visit to http://www.cnn.com I had 207 irrelevant tcp connections hanging after 7 minutes usage. They only accumulate. This is even worse then with http 1.1. A a heap of allocated webshells that for some reason hold the connections are first freed when moz is exited.
->ruslan
Assignee: gagan → ruslan
This is due to a leak of socket transports. Landing the fix now.
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This is still present... I filed bug 35636 about it with Build ID 2000041205 on Windows 98, and was pointed at this. Seeing as I can't reopen this one, I won't mark mine as a dupe.
*** Bug 35643 has been marked as a duplicate of this bug. ***
sorry, not a dupe. please excuse the spam
BTW - it's OK to have up to keep-alive.max-connections (30 by default) to be opened at all times.
ruslan@netscape.com - i filed a "reverse" on the 14th, see bug 35844
*** Bug 35997 has been marked as a duplicate of this bug. ***
>BTW - it's OK to have up to keep-alive.max-connections (30 by default) to be >opened at all times. What if you have several instances of mozilla running? Winsock starts acting up pretty soon after 50 sockets.
We need to find the fine line for default preferences. Obviously it's nice if it's different for different platforms.
It'd be too agressive to close all the sockets when you live certain site. What if you go back? The idle sockets are kept within boundaries of the following options: network.http.keep-alive.max-connections=30 (will never be more then that total # of keep-alive sockets), network.http.keep-alive.max-connections-per-server=8 (never more then that number of sockets per each server), network.http.keep-alive.timeout=300 (sockets are never kept-alive for longer then 300 seconds). Now. The server can send an advisory Keep-Alive header, smth. like Keep-Alive: timeout=xxxseconds,max=maxcon which will further affect the behavior of mozilla. Apache sends 15 seconds in default configuration. We can make these parameters tuned down for Win95 if you feel like they're too agressive. There's no socket leakage however. I double-checked it many times (we had some in the past).
Or. I forgot to mention that there's a bug somewhere in imagelib with anymated gifs when it goes and reads it from netlib over and over. If it happens to be inside of the cache - we're fine (except for an assert on shutdown), otherwise it'll be going over the network, which is not pretty. But it's a different bug.
Agressive closing good. No closing bad. NC4.7's behaviour in this matter is desireable: The previous page is simply cached. The Cache is work in progress in Moz, but this is the way i understand it's intended to work when finished. And if the user wants a refresh - he/she hits "reaload" button. If a "keep alive" isn't specifically requested, connection should even be closed *while* on the site. And again: This is also how NC4.7 operates. There are several history/cache bugs. bug 21137 - "Hook up reload/shift-reload/back/forward buttons to load attributes" bug 32469 - "history to work well with cache" and bug 33269 - "Back/Forward Page Performance is slow compared to IE" They all indicate that back/forward should hit the cache, NOT the server. Quote from bug 21137: ------- Additional Comments From fur@netscape.com 1999-12-13 06:11 ------- One very important thing I forgot to mention: Using the back or forward button should set the load attribute to VALIDATE_NONE, regardless of the cache pref setting. This is so that history navigation doesn't cause a network request to be sent to the server unless, for some reason, the requested page is not in the cache at all. -- (end-of-quote)
Re. animated gif/imagelib bug: Those actually DO read from cache in Moz now - at least cached RAM. Disk-cache is also connected now - i can hardly do a reload anymore ;) But a sample of cache working to some extent: I'm on ppp from home. Night two weeks ago i left Moz open with an animated gif overnight after disconnecting. Got back 10 hours later: Moz had chomped up an additional 4.5 MB RAM in the meanwhile, but the animation was still animating :) There are sites that insist on pushing animations - meta-refreshes or however, but *that's* an entirely different matter. Those are "keep alive" connections (*while on site* !) Was troubleshooting a router one night, and wondered about "alarmingly" frequent hits to a puter in a remote secured daytime office. Originating IP turned out to be doubleclick.com. Doh. That was MSIE btw.
made an attachment in 35844 - relevant to this bug. Perhaps they should be merged, they're the ying and yang of the same problem: Too many versus too few sockets.
*** Bug 36858 has been marked as a duplicate of this bug. ***
*** Bug 39277 has been marked as a duplicate of this bug. ***
verif. Linux 2000070420
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: