[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [Libevent-users] stuck in my accept call :-(
On Fri, Dec 6, 2013 at 1:05 PM, sven falempin <sven.falempin@xxxxxxxxx> wrote:
> On Fri, Dec 6, 2013 at 12:14 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
>> On Thu, Dec 5, 2013 at 12:22 AM, sven falempin <sven.falempin@xxxxxxxxx>
>> > 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.
>> I'm not seeing an obvious problem with that code, assuming that
>> 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?
> it is ktrace :-) it has a binary format you read with kdump. If i reproduce
> i gonna check this.
>> 2) If you're multithreaded, make sure that you've enabled all the
>> locking stuff that you need in libevent.
> done :-) was a bit messy but it looks ok now.
Great. Remember, you need to enable threading before you create any
event_base, and you need to explicitly make any bufferevent or similar
thing that can be used or affected by multiple threads locked.
more details than you necessarily want :)
>> 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.
> I always valgrind (helgrind ?) .
Part of the valgrind suite. Like valgrind, but for muliththreading
>> 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.
Libevent provides a wrapper for accepting TCP connections so that you
don't need to do listen/accept yourself:
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.