I'm still managing to trigger socket exhaustion from time to time - in fact
I think I'm getting better at it. The current sequence is reasonably
reproducible, provided you can find a site that will abort downloads on you
in mid-stream:

1 Load SktCounter

2 Start downloading some large files. Mp3s or something; enough to tax your
connection. I used the ISIHAC collection on archive.org.

3 Find a few image-heavy pages and load one. I suspect the faster your
connection the more pages (and the more image-heavy) you'll need.

4 Before the image-heavy page has finished loading, close it.

5 Load another image-heavy page, or the same one again.

6 At this stage, I still generally see SktCounter hovering at around 60-70
connections. In fact, it either hovers at around 60-80, or it drops to zero;
with my setup I have never ever seen a positive socket count of less than
say, 60.

7 Keep loading pages and then interrupting the page downloads until one of
the large file downloads disconnects.

8 As soon as the large downloads disconnect (NOT completing, but with bytes
to download remaining), I'm finding that my free socket count immediately
drops to 0. So no more internet until I've reset things.


I suspect a combination of an aborted page load (item 4) and one or more
disconnects (8) is the core of the problem. The only significance of the
image-heavy pages, I reckon, is that because they take longer to load it's
easier to interrupt them reliably at a critical point.


If someone else can try this and confirm, then I'll do a proper bug report,
but I would like a sanity check first. I'm also wondering whether it really
is a NetSurf bug; to count the number of sockets available, SockCtr
continually creates and releases them, and it might be that the real problem
is with the (X)Socket_Creat and/or (X)Socket_Close SWIs. Or else a 'blocked'
socket gets created that suddenly renders all the other 60-odd sockets that
should be available inaccessible.


I'm using a 512Mb Iyonix with RO5.14 and dialup.

-- 
Simon Smith

Where there's muck there's hope.

Reply via email to