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

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



On Fri, Dec 13, 2013 at 8:49 AM, sven falempin <sven.falempin@xxxxxxxxx> wrote:
> Hello,
>
> 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 ?

I think that's a pretty good idea.

100% kernel load on accept() is often symptomatic of ENFILE or EMFILE
, and the typical solution -- after raising resource limits as
appropriate, and making sure you don't have a socket leak -- is to do
something in response other than just closing the socket -- like
closing the listener for a while, or until some sockets have closed,
or disabling it, or such.



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