RE: [Libevent-users] epoll erros

2010-10-26 Thread Gilad Benjamini
t > Subject: Re: [Libevent-users] epoll erros > > On Fri, Oct 22, 2010 at 4:25 PM, Nicholas Marriott > wrote: > > I think something needs to walk the file->f_ep_links list on close() > > and remove any epitems where epi->ffd->fd is the fd being closed from > > th

Re: [Libevent-users] epoll erros

2010-10-24 Thread Nicholas Marriott
Hi On Sun, Oct 24, 2010 at 01:03:25PM -0400, Nick Mathewson wrote: > On Fri, Oct 22, 2010 at 4:25 PM, Nicholas Marriott > wrote: > > I think something needs to walk the file->f_ep_links list on close() and > > remove any epitems where epi->ffd->fd is the fd being closed from the > > tree in epi->

Re: [Libevent-users] epoll erros

2010-10-24 Thread Nick Mathewson
On Fri, Oct 22, 2010 at 4:25 PM, Nicholas Marriott wrote: > I think something needs to walk the file->f_ep_links list on close() and > remove any epitems where epi->ffd->fd is the fd being closed from the > tree in epi->ep. > > I don't have a Linux box to try this on though :-). I think you're ri

Re: [Libevent-users] epoll erros

2010-10-22 Thread Nicholas Marriott
I think something needs to walk the file->f_ep_links list on close() and remove any epitems where epi->ffd->fd is the fd being closed from the tree in epi->ep. I don't have a Linux box to try this on though :-). On Fri, Oct 22, 2010 at 09:15:26PM +0100, Nicholas Marriott wrote: > It also looks

Re: [Libevent-users] epoll erros

2010-10-22 Thread Nicholas Marriott
It also looks to me like eventpoll_release is not called until the struct file is released (ie all refs are gone), NOT when the fd is closed. So this means that because it is dup()d it remains on the tree even after close(). Then because you dup() it again _to the same target fd_, when you try to

Re: [Libevent-users] epoll erros

2010-10-22 Thread Nicholas Marriott
On a quick look it seems to me like epoll keys the tree on the epoll fd by both underlying struct file and the file descriptor itself, so it should work with dup()d fds. On Fri, Oct 22, 2010 at 08:42:13PM +0100, Nicholas Marriott wrote: > If this is right it seems really stupid and inconvenient.

RE: [Libevent-users] epoll erros

2010-10-22 Thread Gilad Benjamini
> Apparently, the Linux kernel associates epoll state with files in such > a way that the epoll state is shared across dup()'d fds. I'll read the > kernel source a little more to be sure of what's happening. I've > attached a variant of my test code to reproduce this. Thanks, Gilad, > for all y

Re: [Libevent-users] epoll erros

2010-10-22 Thread Nicholas Marriott
If this is right it seems really stupid and inconvenient. Sounds more like a bug to me. I add dup()d fds to libevent and haven't had any complaints from Linux users. Although I don't remove and add them (or read and write from both at the same time, I think). dup()d fds definitely seems to work w

Re: [Libevent-users] epoll erros

2010-10-22 Thread Nick Mathewson
On Fri, Oct 22, 2010 at 1:54 PM, Nick Mathewson wrote: [...] > Actually, straceing the application up to the point where it gets its > first message like > > [warn] Epoll ADD(1) on fd 13 failed.  Old events were 0; read change > was 1 (add); write change was 0 (none): File exists > > would proba

Re: [Libevent-users] epoll erros

2010-10-22 Thread Nicholas Marriott
t 12:20 AM, Gilad Benjamini > wrote: > >> -Original Message- > >> From: Nick Mathewson > >> Sent: Tuesday, September 21, 2010 7:43 PM > >> To: libevent-us...@freehaven.net > >> Subject: Re: [Libevent-users] epoll erros > >> ... > >

RE: [Libevent-users] epoll erros

2010-10-22 Thread Gilad Benjamini
> -Original Message- > From: owner-libevent-us...@freehaven.net [mailto:owner-libevent- > us...@freehaven.net] On Behalf Of Nick Mathewson > Sent: Friday, October 22, 2010 11:19 AM > To: libevent-us...@freehaven.net > Subject: Re: [Libevent-users] epoll erros > >

Re: [Libevent-users] epoll erros

2010-10-22 Thread Nick Mathewson
us...@freehaven.net >> Subject: Re: [Libevent-users] epoll erros >> > ... >> It won't catch attempts to manually reassign the event's ev_events >> while the event is added.  I sure hope nobody is doing that.  Don't >> touch struct event's fields by

RE: [Libevent-users] epoll erros

2010-10-22 Thread Gilad Benjamini
> -Original Message- > From: owner-libevent-us...@freehaven.net [mailto:owner-libevent- > us...@freehaven.net] On Behalf Of Nick Mathewson > Sent: Friday, October 22, 2010 10:39 AM > To: libevent-us...@freehaven.net > Subject: Re: [Libevent-users] epoll erros >

Re: [Libevent-users] epoll erros

2010-10-22 Thread Nick Mathewson
On Fri, Oct 22, 2010 at 1:38 PM, Nick Mathewson wrote: [...] > 4 is conceivable under a couple of weird circumstances.  Might there > be more than one event_base in the application, so that fd 13 is > actually getting added/removed from separate event_bases?  Might there > be multithreading issue

Re: [Libevent-users] epoll erros

2010-10-22 Thread Nick Mathewson
?] On Fri, Oct 22, 2010 at 12:20 AM, Gilad Benjamini wrote: >> -Original Message- >> From: Nick Mathewson >> Sent: Tuesday, September 21, 2010 7:43 PM >> To: libevent-us...@freehaven.net >> Subject: Re: [Libevent-users] epoll erros >> ... >> >&

Re: [Libevent-users] epoll erros

2010-09-22 Thread Nick Mathewson
On Wed, Sep 22, 2010 at 11:53 AM, Gilad Benjamini wrote: >> >> 2010/9/21 Gilad Benjamini : >>  [...] >> > Any chance you can hmake something out of the attached log ? >> >> That's pretty helpful!  It's almost but not quite enough information >> to figure out what's up here.  There are a couple of

RE: [Libevent-users] epoll erros

2010-09-22 Thread Gilad Benjamini
> > 2010/9/21 Gilad Benjamini : > [...] > > Any chance you can hmake something out of the attached log ? > > That's pretty helpful! It's almost but not quite enough information > to figure out what's up here. There are a couple of epoll debugging > messages that don't give enough detail. > >

Re: [Libevent-users] epoll erros

2010-09-21 Thread Nick Mathewson
2010/9/21 Gilad Benjamini : [...] > Any chance you can make something out of the attached log ? That's pretty helpful! It's almost but not quite enough information to figure out what's up here. There are a couple of epoll debugging messages that don't give enough detail. I just added a couple

Re: [Libevent-users] epoll erros

2010-09-20 Thread Nick Mathewson
On Fri, Sep 17, 2010 at 3:06 PM, Gilad Benjamini wrote: >> The first thing to do here is to use event_enable_debug_mode() to have >> libevent track event adds/deletes/etc to make sure that there's >> nothing screwy going on there. (Did this turn anything up? You don't need to build with any spec

RE: [Libevent-users] epoll erros

2010-09-17 Thread Gilad Benjamini
> The first thing to do here is to use event_enable_debug_mode() to have > libevent track event adds/deletes/etc to make sure that there's > nothing screwy going on there. > Here is the chain of events I was able to identify - An event for fd 14 is created - At some later point, my code deletes th

RE: [Libevent-users] epoll erros

2010-09-17 Thread Gilad Benjamini
> The first thing to do here is to use event_enable_debug_mode() to have > libevent track event adds/deletes/etc to make sure that there's > nothing screwy going on there. > Beside calling event_enable_debug_mode I understand I have to turn on debugging. How would I do that ? configure --enable-

Re: [Libevent-users] epoll erros

2010-09-17 Thread Nick Mathewson
On Thu, Sep 16, 2010 at 2:59 PM, Gilad Benjamini wrote: > My Linux code, which uses libevent 2.0.x occasionally prints these error > messages >    Epoll ADD on fd 14 failed.  Old events were 0; read change was 1 (add); > write change was 0 (none).: File exists > When they appear, it can be as freq

[Libevent-users] epoll erros

2010-09-16 Thread Gilad Benjamini
My Linux code, which uses libevent 2.0.x occasionally prints these error messages Epoll ADD on fd 14 failed. Old events were 0; read change was 1 (add); write change was 0 (none).: File exists When they appear, it can be as frequent as once a second. Can someone shed some light on what the is