syscall vmsplice gives a lot of : *** glibc detected *** trinity: malloc(): smallbin double linked list corrupted:

["Toralf Förster" <toralf.foerster@gmx.de>]

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@redhat.com>
[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