I was just trying out a new (well, new to me...) machine here. It
happens that the version of Linux installed is 3.2.78. Apparently the
current version on this branch is 3.2.80 released a couple months ago
and I don't see any relevant changes in .79 or .80 so I think this is
actually likely to be the behaviour in a "supported" version of Linux.
What I'm seeing is that every call to epoll_wait() raises EFAULT. I
don't see anything wrong with the arguments to epoll_wait so unless
there was some earlier bogus argument to epoll_ctl or something this
looks like some kind of kernel or glibc problem and it looks like
we'll to check for EFAULT and fall back to poll (a configure test
wouldn't help since this is run-time behaviour).
Breakpoint 1, WaitEventSetWaitBlock (set=0x9c0a88, cur_timeout=-1, occurred_events=0xff88f4f8, nevents=1) at
latch.c:975
975 int returned_events = 0;
(gdb) n
981 rc = epoll_wait(set->epoll_fd, set->epoll_ret_events,
(gdb) p *set
$9 = {nevents = 3, nevents_space = 3, events = 0x9c0aa4, latch = 0xf75a9808, latch_pos = 1, epoll_fd = 3,
epoll_ret_events= 0x9c0ad4}
(gdb) p *set->epoll_ret_events
$10 = {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}
(gdb) p nevents
$11 = 1
(gdb) p cur_timeout
$12 = -1
(gdb) n
Breakpoint 3, WaitEventSetWaitBlock (set=0x9c0a88, cur_timeout=-1, occurred_events=0xff88f4f8, nevents=1) at
latch.c:985
985 if (rc < 0)
(gdb) p rc
$13 = -1
(gdb) p errno
$14 = 14
--
greg