[Libevent-users] bug in epoll.c ?

2009-03-06 Thread Alon Noy
When I'm running my libevent based application under valgrind I'm
getting messages about memory access violations in epoll.c. when
changing line 125 from:

nfiles = rl.rlim_cur - 1;

to:

nfiles = rl.rlim_cur;

then the application runs with no complains from valgrind. The problems
shows when reaching the limit of allowed open file descriptors.

From the remark above this line I understand that the -1 was hacked in
because some issue with Solaris but was it ever tested with other
platforms?

 

I'm running libevent 1.4.9-stable on ubuntu linux
2.6.27-11-generic(SMP).

 

Thanks

___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users


Re: [Libevent-users] UDP and TCP Communications

2009-03-06 Thread Brian
No fork() involved actually. Here is an example code

#include1.c

void func1() {
struct event ev;
event_set(ev, /*udp socket*/);
event_add(ev, NULL);
}

#include2.c

void func2() {
struct event ev;
event_set(ev, /*tcp socket*/);
event_add(ev, NULL);
}

#main.c
int main() {
event_init();
func1();
func2();
event_dispatch();
}

Both are setup using EV_READ | EV_PERSIST... again, UDP works fine,
but TCP segfaults. I have to maintain a few servers running this
program so I'd like to be able to use the distributed lib instead of
having to maintain my own builds across multiple platforms. And with
this working fine by doing all of event_init() event_dispatch() in
each function (doing the event setup within it's own thread for the
TCP socket) both servers worked fine. It's only when I try to
implement them both together in what appears to be a proper
implementation that I get this error.

Thank you,

-brian



On Fri, Mar 6, 2009 at 3:20 AM, Niels Provos pro...@gmail.com wrote:
 On Thu, Mar 5, 2009 at 9:10 AM, Brian ping...@gmail.com wrote:
 I have a thread safe application that I am using to host a UDP service
 on. This program also has a TCP based admin process to grab stats and
 update internals for the program during run-time. Before I had
 event_init() event_dispatch() running in their own threads, but I
 wanted to make things more proper. So in main() I have event_init()
 and event_dispatch() while performing event_set() and event_add() in
 their own respected processes. This has structure has multiple
 benefits for me. I am on an Ubuntu feisty install. Everything still
 works with UDP perfectly, however when I attempt to connect to the TCP
 port epoll_dispatch() SIGSEGV's

 When you say in in their own respected processes, does that mean you
 fork?  After fork you need to call event_reinit() to setup the epoll
 structures again.   The epoll fd does not survive across forks.   You
 will have to upgrade to libevent-1.4.x for that.

 Niels.

___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users


Re: [Libevent-users] UDP and TCP Communications

2009-03-06 Thread Nick Mathewson
On Fri, Mar 06, 2009 at 09:16:26AM -0500, Brian wrote:
 Thanks Guillaume for the feedback. Unfortunately malloc/calloc method
 didn't work for me. I think I will just go back to how it was. Does
 anyone know if there is an inherent flaw, perhaps, with doing the
 event_init()/event_dispatch() within a posix thread?

Guillaume is right.  In the sample code you posted, the memory used to
hold the struct events on the stack will not continue to be reserved
after the function exits, so a call to another function can totally
overwrite it.  This isn't a pthreads thing.

(To answer your threading question:  in Libevent 1.4.x, it's okay to
do nearly anything from inside a thread, but only one thread can
safely use a given event_base at a time.  Also, if you're using
threads with Libevent 1.4.x, you need to make sure that you always
specify event_base objects explicitly, and use event_base_set on each
new event.  Otherwise, calls to functions will generally use the most
recently initialized event_base, leading to race conditions.)

-- 
Nick

___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users