[webkit-gtk] 1.4.1 - CLOSE_WAIT

[Marco Peereboom]

On Thu, Jun 30, 2011 at 09:54:34AM -0500, Marco Peereboom wrote:
> On Wed, Jun 29, 2011 at 06:27:30PM -0500, Marco Peereboom wrote:
> > On Wed, Jun 29, 2011 at 04:23:00PM -0700, Martin Robinson wrote:
> > > On Wed, Jun 29, 2011 at 2:43 PM, Marco Peereboom <slash at peereboom.us> wrote:
> > > 
> > > > This is with the webkit 1.4.1 snapshot with web sockets enabled. ??By
> > > > default xxxterm sets max-conns to 25 and max-conns-per-host to 5. ??When
> > > > webkit doesn't crash I see as many as 119 connections to port 80 in
> > > > various states (TIME_WAIT, ESTABLISHED, CLOSED_WAIT, SYN_SENT etc).
> > > > After a while the connections drop to 47 and are all in
> > > > ESTABLISHED_STATE. ??This number is obviously much higher than the limit
> > > > that is set to 25. ??With webit 1.2.7 I don't see this behavior.
> > > 
> > > Do you mind confirming whether this behavior persists with WebSockets disabled?
> > 
> > Nope not at all.  I have toyed but do not have a detailed report.  My
> > non-scientific test was "better" but not gone.  For example the
> > CLOSED_WAIT number seems to be gone completely but it still breaches the
> > max-conns setting and I see similar crashes.  I will do the build and
> > generate an actual report.
> 
> Ok, the results are as I described with web sockets disabled.  Better as
> in webkit does close file descriptors much quicker however the
> fundamental issues of breaching the max-conns limit is still there.

So I found the bug that causes this however I do not have a patch.  What
happens is that in my browser I set max-conns and max-conns-per-host
right after obtaining the default session.  Like so:

	session = webkit_get_default_session();
	g_object_set(session, "max-conns", max_connections, (char *)NULL);
	g_object_set(session, "max-conns-per-host", max_host_connections,
	    (char *)NULL);

Problem is that webkit will overwrite these values upon "first contact"
with a site.  The responsible file is:
WebCore/platform/network/soup/ResourceHandleSoup.cpp in function
static void ensureSessionIsInitialized(SoupSession* session)
    static const int maxConnections = 60;
    static const int maxConnectionsPerHost = 6;
...
    g_object_set(session,
                 SOUP_SESSION_MAX_CONNS, maxConnections,
                 SOUP_SESSION_MAX_CONNS_PER_HOST, maxConnectionsPerHost,
                 NULL);

This code is run AFTER I set those values.  I am drawing a blank on how
to initialize webkit to a point where I can overwrite those values with
something that makes sense in my environment.

Any clues?

> When I launch the browser with all those links at once it opens up about
> 67 file descriptors and none end up in CLOSED_WAIT initially.  Instead
> one sees ESTABLISHED and TIME_WAIT.  In other words when running without
> web sockets the inevitable is just postponed a little.  A couple of
> quick restarts and webkit exhibits the same crashes.  I do see the same
> misrendered pages as described before, even when starting on a fresh
> machine (virtually no FDs in use).

This seems to be fixable by doing something like this:
--- Source/WebCore/platform/graphics/FontFallbackList.cpp.orig	Fri Jul  8 14:05:45 2011
+++ Source/WebCore/platform/graphics/FontFallbackList.cpp	Fri Jul  8 14:06:48 2011
@@ -73,7 +73,14 @@ void FontFallbackList::releaseFontData()
 
 void FontFallbackList::determinePitch(const Font* font) const
 {
+    if (font == NULL)
+	return;
+
     const FontData* fontData = primaryFontData(font);
+
+    if (fontData == NULL)
+	return;
+
     if (!fontData->isSegmented())
         m_pitch = static_cast<const SimpleFontData*>(fontData)->pitch();
     else {

> For completions sake, this is using webkit 1.4.1 and libsoup 2.34.2 and
> I do not see these issues when I used webkit 1.2.x and libsoup 2.32.y.
> I also validated that I see these same issues using other browsers such
> as epiphany and midori.
> 
> I'll be happy to run some additional tests or dig in the code if you
> point me in a potential direction.
> 
> > 
> > > 
> > > --Martin

I see some more issues and will write separate emails for those.