sysno == 205 exp-ptrcheck: the 'impossible' happened: unhandled syscall ==00:00:06:21.577 13254== at 0x3801249B: report_and_quit (m_libcassert.c:140) ==00:00:06:21.577 13254== by 0x38012763: panic (m_libcassert.c:215) ==00:00:06:21.577 13254== by 0x38012832: vgPlain_tool_panic (m_libcassert.c:230) ==00:00:06:21.577 13254== by 0x38004D0D: h_post_syscall (h_main.c:2486) ==00:00:06:21.577 13254== by 0x3803C6CD: vgPlain_post_syscall (syswrap-main.c:1178) ==00:00:06:21.577 13254== by 0x3803C03C: vgPlain_client_syscall (syswrap-main.c:1090) ==00:00:06:21.577 13254== by 0x3803A18F: handle_syscall (scheduler.c:824) ==00:00:06:21.577 13254== by 0x3803A79E: vgPlain_scheduler (scheduler.c:1018) ==00:00:06:21.577 13254== by 0x3803D87F: thread_wrapper (syswrap-linux.c:89) ==00:00:06:21.577 13254== by 0x3803D9BF: run_a_thread_NORETURN (syswrap-linux.c:122) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==00:00:06:21.577 13254== at 0x8A10B3: getgroups (in /lib/libc-2.5.so) ==00:00:06:21.577 13254== by 0x4AF48C0: Unix::TNUnixContext::vosUserId(int*, int*, int*) (unix_user.cpp:294) ==00:00:06:21.577 13254== by 0x4ABA026: v_user_id (vos_user.cpp:100) ==00:00:06:21.577 13254== by 0x4DC5D76: c_req_id_to_server (req_clt_cv.c:2043) ==00:00:06:21.577 13254== by 0x4DC42E1: open_server_port (req_clt_cv.c:919) ==00:00:06:21.577 13254== by 0x4DC46B4: open_server (req_clt_cv.c:1108) ==00:00:06:21.577 13254== by 0x40F16E4: ApiConnectionOpen (api_clt.c:3601) ==00:00:06:21.577 13254== by 0x41913BE: TNConnectionOpenEx (TNGeneric.c:780) ==00:00:06:21.577 13254== by 0x805324E: TiNa_restore (cmd_restore.c:234) ==00:00:06:21.577 13254== by 0x8049EA2: main (TiNa_restore.c:14)
If this is x86-linux then 205 should be getgroups32 which we seem to implement. What architecture is this machine?
It's a virtual machine running on ESX running 32-bit CentOS: $ uname -a Linux bounty.fr.atempo.network 2.6.18-128.1.10.el5 #1 SMP Thu May 7 10:39:21 EDT 2009 i686 i686 i386 GNU/Linux
That's very odd then - are you sure it's valgrind 3.4.1 you're running?
Yes, I downloaded and compiled it this morning: $ which valgrind /DT/DEV/people/kstock/bin/valgrind $ valgrind --version valgrind-3.4.1
Ah, it's ptrcheck that's complaining, not the core - that explains it.
Fixed in r10479.