On Thu, Dec 5, 2013 at 12:22 AM, sven falempin <sven.falempin@xxxxxxxxx> wrote:I'm not seeing an obvious problem with that code, assuming that
> hello:
>
> libevent-2.0.21-stable
>
> https://forums.freebsd.org/viewtopic.php?f=35&t=43654&p=242811#p242811
>
> event_assign(&serv_sock_evt, evt_base,
> Â Â Â sock, EV_READ | EV_PERSIST,
> Â Â Â server::serv_sock_accept_pattern, this);
> event_add(&serv_sock_evt, NULL);
>
> then i do new in server::serv_sock_accept_pattern and path the arguments to
> accept.
>
> But apparently socket has nothing to accept.
>
> It is not easy to produce....
>
> help/insight welcome.
server::serv_sock_accept_pattern has the right signature and is
declared as 'cdecl' if that's necessary. ÂIf you're doing anything
unusual with threads, that could account for a socket appearing
readable but having nothing to accept when you look at it .. but you
probably would have thought of that.
A few possibly-not-too-helpful thoughts I have for debugging:
 1) use strace or truss or whatever the best FreeBSD syscall logging
tool is to see what exactly is going on with the fd in question. ÂAre
there weird syscalls happening to it? ÂIs something calling accept()
twice somehow?
 2) If you're multithreaded, make sure that you've enabled all the
locking stuff that you need in libevent.
 3) If you haven't done so already, use helgrind and valgrind to look
for whether some kind of fishy corruption might be going on.
 4) Try to come up with a minimal program and/or testing environment
to reproduce the failing case.
 5) If it's not too hard, try dropping in evconnlistener in place of
your current listen/accept logic and see if the problem persists. If
not, it's likely an issue in your code somewhere.
 6) If you're using any awesome freebsd features like accept filters
that might affect this code path, try turning them off to see whether
that helps.
I hope one of those ideas is helpful. ÂGood luck!
yrs,
--
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users  Âin the body.