cache_acceptor_poll.c oddities (Solaris)

[Jyri J. Virkki]

Hello,

Starting varnish (current code from svn) on Solaris, without any
requests I see it sits there with one thread using up all of 1 cpu,
stuck in a poll loop (per truss).

I see on Solaris it ends up using cache_acceptor_poll.c by default and
the problem is that vca_main() calls poll with a pollfd mostly full of
bad data.

Happens because vca_poll() is called earlier once with one fd (fd=7
here) and so it initializes pollfd[7], but all of pollfd[1..6] remain
uninitialized. I see code in vca_pollspace() that presumably attempted to
initialize the space but doesn't really (the loop only sets "p->fd = -1"
with a constant p so only the 0th entry is initialized).  It seems as if
the code was really wanting to do something like shown in diff below?

Presumably this must be working correctly on other platforms so before
filing a bug I thought I'd ask if I'm missing something obvious.
I'll try it on my Linux box later to see what's different. (This diff
isn't enough to make it work at all on Solaris, there are other
problems I see, but wanted to clarify this bit first).

Thanks...


Index: cache_acceptor_poll.c
===================================================================
--- cache_acceptor_poll.c       (revision 2590)
+++ cache_acceptor_poll.c       (working copy)
@@ -58,6 +58,7 @@
 {
        struct pollfd *p;
        unsigned u, v;
+       unsigned oldnpoll = npoll;
 
        if (fd < npoll)
                return;
@@ -69,26 +70,40 @@
        p = realloc(pollfd, u * sizeof *p);
        XXXAN(p);       /* close offending fd */
        memset(p + npoll, 0, (u - npoll) * sizeof *p);
-       for (v = npoll ; v <= u; v++)
-               p->fd = -1;
+       for (v = oldnpoll ; v < u; v++)
+               (p+v)->fd = -1;
        pollfd = p;
        npoll = u;
 }


-- 
Jyri J. Virkki - Santa Cruz, CA






--