Re: [Libevent-users] stuck in my accept call :-(

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

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>
>> wrote:
>> > 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.

http://www.wangafu.net/~nickm/libevent-book/Ref1_libsetup.html has
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
errors: http://valgrind.org/docs/manual/hg-manual.html

>>   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:

http://www.wangafu.net/~nickm/libevent-book/Ref8_listener.html


best wishes,
-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.