When I tried the syscall vmsplice under a 32 bit (Gentoo Linux) user mode linux I get tons of : tfoerste@n22 ~ $ trinity.sh -c vmsplice starting trinity at Thu Apr 18 18:08:06 CEST 2013 using /mnt/n22 ... Trinity v1.2pre Dave Jones <davej@xxxxxxxxxx> [2036] Marking syscall vmsplice (316) as to be enabled. Done parsing arguments. [2036] Enabled 1 syscalls. Disabled 350 syscalls. [2036] Started watchdog process, PID is 2037 [2038] Main thread is alive. Generating file descriptors Added 201 filenames from /mnt/n22/w/victims *** glibc detected *** trinity: malloc(): smallbin double linked list corrupted: 0x080ca370 *** trinity: malloc.c:3790: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed. trinity: malloc.c:3790: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed. *** glibc detected *** trinity: corrupted double-linked list: 0x080cd130 *** trinity: malloc.c:3790: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed. *** glibc detected *** trinity: malloc(): smallbin double linked list corrupted: 0x080c4930 *** trinity: malloc.c:3790: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed. [2037] Watchdog is alive So I just gave valgrind a try : $ valgrind --leak-check=yes trinity --children 4 --victims /mnt/n22/w/victims -N 50000 --quiet -c vmsplice ==1065== Memcheck, a memory error detector ==1065== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==1065== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==1065== Command: trinity --children 4 --victims /mnt/n22/w/victims -N 50000 --quiet -c vmsplice ==1065== vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x40 ==1065== valgrind: Unrecognised instruction at address 0x40149a0. ==1065== at 0x40149A0: _dl_sysdep_start (in /lib/ld-2.15.so) ==1065== by 0xFFF: ??? ==1065== Your program just tried to execute an instruction that Valgrind ==1065== did not recognise. There are two possible reasons for this. ==1065== 1. Your program has a bug and erroneously jumped to a non-code ==1065== location. If you are running Memcheck and you just saw a ==1065== warning about a bad jump, it's probably your program's fault. ==1065== 2. The instruction is legitimate but Valgrind doesn't handle it, ==1065== i.e. it's Valgrind's fault. If you think this is the case or ==1065== you are not sure, please let us know and we'll try to fix it. ==1065== Either way, Valgrind will now raise a SIGILL signal which will ==1065== probably kill your program. ==1065== ==1065== Process terminating with default action of signal 4 (SIGILL): dumping core ==1065== Illegal opcode at address 0x40149A0 ==1065== at 0x40149A0: _dl_sysdep_start (in /lib/ld-2.15.so) ==1065== by 0xFFF: ??? ==1065== ==1065== HEAP SUMMARY: ==1065== in use at exit: 0 bytes in 0 blocks ==1065== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==1065== ==1065== All heap blocks were freed -- no leaks are possible ==1065== ==1065== For counts of detected and suppressed errors, rerun with: -v ==1065== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction which immediately exits complaining about that illegal instructions. Is this just related to valgrind or is this a trinity thing ? -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe trinity" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
