Looks like ptrcheck doesn't handle the epoll_create system call: sysno == 254 exp-ptrcheck: the 'impossible' happened: unhandled syscall ==7181== at 0x3800EB9B: report_and_quit (m_libcassert.c:140) ==7181== by 0x3800EC5A: panic (m_libcassert.c:215) ==7181== by 0x3800ECC1: vgPlain_tool_panic (m_libcassert.c:230) ==7181== by 0x38003E4E: h_post_syscall (h_main.c:2486) ==7181== by 0x3802F73B: vgPlain_post_syscall (syswrap-main.c:1178) ==7181== by 0x3802FC77: vgPlain_client_syscall (syswrap-main.c:1090) ==7181== by 0x3802D986: vgPlain_scheduler (scheduler.c:824) ==7181== by 0x38030BBE: run_a_thread_NORETURN (syswrap-linux.c:89) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==7181== at 0x82E5E2: epoll_create (in /lib/tls/libc-2.3.4.so) ==7181== by 0x4643DB0: MCON_FDConn_Handler_EPoll::default_instance() (mcon_fdconn_handler_epoll.C:155) (rest of stack trace is our code) running on: Linux daudc1 2.6.9-42.ELsmp #1 SMP Sat Aug 12 09:39:11 CDT 2006 i686 i686 i386 GNU/Linux
Just a heads-up: there's also now epoll_create1(), which interprets the single integer parameter as a flags argument (ala accept4() and friends): --607-- WARNING: unhandled syscall: 291 --607-- You may be able to write your own handler. --607-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --607-- Nevertheless we consider this a bug. Please report --607-- it at http://valgrind.org/support/bug_reports.html. code: #ifdef EPOLL_CLOEXEC { int trueflags = 0; if(flags & LIBDANK_EVHANDLER_CLOEXEC){ trueflags |= EPOLL_CLOEXEC; } if(flags & LIBDANK_EVHANDLER_NONBLOCK){ trueflags |= EPOLL_NONBLOCK; } if((fd = epoll_create1(trueflags)) < 0){ moan("Couldn't create epoll fd with flags %x\n",flags); return NULL; } } #else
Support for epoll_create1 in the core (not ptrcheck) was added a few days ago in r10427.
Support for epoll_create and epoll_create1 in ptrcheck committed as r10635.