[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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


I add a bug related to multithread, but it was just some noise.
Just to be even more sure i useÂevutil_make_socket_nonblocking now.

I am now at like 12hours or more before reproducing the problem, so next time i will probably focus on lowering the backlog number.

(gdb) bt
#0 Â0x00000000004acf7c in __sys_accept ()
#1 Â0x0000000000492ca0 in accept ()
#2 Â0x00000000004299cb in listener_read_cb (fd=7, what=<optimized out>, p=<optimized out>) at listener.c:396
#3 Â0x0000000000427d6e in event_process_active_single_queue (activeq=0x800867050, base=<optimized out>) at event.c:1350
#4 Âevent_process_active (base=<optimized out>) at event.c:1420
#5 Âevent_base_loop (base=0x800868300, flags=<optimized out>) at event.c:1621
#6 Â0x000000000041b0ef in main (argc=10, argv=0x7fffffffdb88) at main.cc:261

My question is:
Maybe adding the error callback would help ?

My fear is, as the core is running at 100% looks like a bug in the kernel (i mean event a block mode accept does not raise the load like this ?)

As a first workaround i am thinking calling a poll before the accept, unless someone as a better idea. (Even if i imagine a threaded close call on fd 7 that should just return Exxx)

thx for insight.

On Fri, Dec 6, 2013 at 1:11 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
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:


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

() ascii ribbon campaign - against html e-mailÂ