|
From: Hauke M. <ha...@ha...> - 2016-10-01 13:54:22
|
Hi, With valgrind 3.11 I am always getting this error when trying to use valgrind: ------------------------------------------------------------------------ root@lede:/# valgrind uname -a valgrind: mmap(0x400000, 303104) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. root@lede:/# ------------------------------------------------------------------------ Then I tried the current svn snapshot from version r15986 and I am getting this error: ------------------------------------------------------------------------ root@lede:/# valgrind uname -a ==1174== Memcheck, a memory error detector ==1174== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==1174== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info ==1174== Command: uname -a ==1174== ==1174== Conditional jump or move depends on uninitialised value(s) ==1174== at 0x4072D14: ??? (in /lib/libc.so) ==1174== by 0x4082930: ??? (in /lib/libc.so) ==1174== ==1174== Conditional jump or move depends on uninitialised value(s) ==1174== at 0x4072454: ??? (in /lib/libc.so) ==1174== by 0x40728C8: ??? (in /lib/libc.so) ==1174== vex mips->IR: unhandled instruction bytes: 0x41 0x67 0x25 0x22 ==1174== valgrind: Unrecognised instruction at address 0x4078a5. ==1174== at 0x4078A5: ??? (in /bin/busybox) ==1174== by 0x401E5D0: ??? (in /lib/libc.so) ==1174== Your program just tried to execute an instruction that Valgrind ==1174== did not recognise. There are two possible reasons for this. ==1174== 1. Your program has a bug and erroneously jumped to a non-code ==1174== location. If you are running Memcheck and you just saw a ==1174== warning about a bad jump, it's probably your program's fault. ==1174== 2. The instruction is legitimate but Valgrind doesn't handle it, ==1174== i.e. it's Valgrind's fault. If you think this is the case or ==1174== you are not sure, please let us know and we'll try to fix it. ==1174== Either way, Valgrind will now raise a SIGILL signal which will ==1174== probably kill your program. ==1174== ==1174== Process terminating with default action of signal 4 (SIGILL) ==1174== Illegal opcode at address 0x4078A5 ==1174== at 0x4078A5: ??? (in /bin/busybox) ==1174== by 0x401E5D0: ??? (in /lib/libc.so) ==1174== ==1174== HEAP SUMMARY: ==1174== in use at exit: 0 bytes in 0 blocks ==1174== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==1174== ==1174== All heap blocks were freed -- no leaks are possible ==1174== ==1174== For counts of detected and suppressed errors, rerun with: -v ==1174== Use --track-origins=yes to see where uninitialised values come from ==1174== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) Illegal instruction root@lede:/# uname -a Linux lede 4.4.23 #0 Fri Sep 30 18:08:21 2016 mips GNU/Linux root@lede:/# valgrind --version valgrind-3.12.0.SVN ------------------------------------------------------------------------ With bspatch in valgrind svn I can make the impossible happen ------------------------------------------------------------------------ root@lede:/# valgrind bspatch ==1211== Memcheck, a memory error detector ==1211== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==1211== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info ==1211== Command: bspatch ==1211== ==1211== Conditional jump or move depends on uninitialised value(s) ==1211== at 0x4072D14: ??? (in /lib/libc.so) ==1211== by 0x4082930: ??? (in /lib/libc.so) ==1211== ==1211== Conditional jump or move depends on uninitialised value(s) ==1211== at 0x4072454: ??? (in /lib/libc.so) ==1211== by 0x40728C8: ??? (in /lib/libc.so) ==1211== vex mips->IR: unhandled instruction bytes: 0x40 0x74 0x4 0x67 vex: priv/guest_mips_toIR.c:1001 (jmp_lit32): Assertion `dres->whatNext == Dis_Continue' failed. vex storage: T total 25185864 bytes allocated vex storage: P total 0 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==1211== at 0x3805DD5C: ??? (in /usr/lib/valgrind/memcheck-mips32-linux) ==1211== by 0x3805DD48: ??? (in /usr/lib/valgrind/memcheck-mips32-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 1211) ==1211== at 0x4008E1: ??? (in /usr/bin/bspatch) ==1211== by 0x401E5D0: ??? (in /lib/libc.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. root@lede:/# bspatch bspatch: usage: bspatch oldfile newfile patchfile root@lede:/# ------------------------------------------------------------------------ This is LEDE (OpenWrt) with kernel 4.4, gcc 5.4.0, musl 1.1.15 and a MIPS Big Endian CPU. The system is build without floating point support (MIPS 34Kc CPU without FPU, kernel without FPU emulation and GCC without FPU support) To make this work this patch is needed: https://git.lede-project.org/?p=source.git;a=blob;f=package/devel/valgrind/patches/130-mips_fix_soft_float.patch What is wrong in the current svn version of valgrind? What commit fixed the problem in the version 3.11 so that I can backport it to the released version? Hauke |
|
From: Petar J. <mip...@gm...> - 2016-10-03 14:46:55
|
Hi Hauke, Does any of these packages use mips16 code? (Valgrind currently does not support mips16.) Can you do 'readelf -h yourbinary' for the binaries that have issues with the latest Valgrind? Run the same command for /lib/libc.so. Regards, Petar |
|
From: Hauke M. <ha...@ha...> - 2016-10-03 15:33:34
|
On 10/03/2016 04:46 PM, Petar Jovanovic wrote: > Hi Hauke, > > Does any of these packages use mips16 code? (Valgrind currently does > not support mips16.) > Can you do 'readelf -h yourbinary' for the binaries that have issues > with the latest Valgrind? Run the same command for /lib/libc.so. > > Regards, > Petar > Hi Petar, Thanks for the hint, yes I was using mips16 and after deactivating mips16 it works. It would be nice to have a better error message when a unsupported mips16 binary is used. To fix the "valgrind: mmap(0x400000, 303104) failed in UME with error 22 (Invalid argument)." problem in valgrind 3.11.0, a backport of commit r15754 "mips: remove link script exception for MIPS arch" is needed, this is included in 3.12.0.BETA1. Hauke |