[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 12:45 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
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.

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

I guess it was a thread that was closing the fd meanwhile the accept (after poll, because i have no errors).
Because it tooks time i did refactoring , and it s only after I refactor something thats this potential bad close became obvious. At the moment i am still unsure what is happening :-(

But i wonder about this valgrind errors (i have symbols):

==11532== Conditional jump or move depends on uninitialised value(s)
==11532== Â Âat 0x4E1757: stpcpy (in /home/myself/jsonserver/bin/jsonserver-debug)
==11532== Â Âby 0x4C8CE1: tzset_basic (in /home/myself/jsonserver/bin/jsonserver-debug)
==11532== Â Âby 0x1C: ???
==11532== Â Âby 0x38353A3130203930: ???
==11532== Â Âby 0x3331303220333439: ???
==11532== Â Âby 0x42A151: event_changelist_add (evmap.c:656)
==11532== Â Âby 0x62072439DF6F8FDB: ???
==11532== Â Âby 0x77393F: ??? (in /home/zvn/jsonserver/bin/jsondb-debug)
==11532== Â Âby 0x176F: ???
==11532== Â Âby 0x7FF00053F: ???
==11532== Â Âby 0x7FF000B1F: ???
==11532== Â Âby 0x7FF000AB7: ???
==11532== ÂUninitialised value was created by a stack allocation
==11532== Â Âat 0x4C92F0: asctime_r (in /home/myself/jsonserver/bin/jsonserver-debug)

and another less important here (when calling vsyslog), i blameÂarglist
void log(int lvl,const char* d,...) {
 va_list arglist;
 if (d && *d) {
  va_start( arglist, d );
  if (gconf.debug || gconf.verbose || lvl != LOG_DEBUG) { //drop log DEBUG if not -d
   vsyslog(lvl, d, arglist);

i am talking about this one because it also mentionÂ

(i check all my <stack> allocation )

I really have no clue for now.

evmap.c 656 isÂchange = event_changelist_get_or_construct(changelist, fd, old, fdinfo); in my 2.0.21 stable.

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