|
From: tzviel l. <tz...@gm...> - 2015-08-04 11:59:45
|
Hello dear forum members, I installed Valgrind on my openWRT, ARMV7 machine, and tried to use it in the following manner: valgrind --leak-check=yes <application name> in return, I got the following response: ==1517== Invalid read of size 4 ==1517== at 0x48C1950: ??? (in /lib/libuClibc-0.9.33.2.so) ==1517== Address 0xbdb60c1c is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes The same case happen with any other application I've tried to run. It seems to me that I have some low-level configuration issue, but I couldn't find it. I would appreciate your opinion on this. Thanks, Tzviel |
|
From: John R. <jr...@bi...> - 2015-08-04 12:41:37
|
> I installed Valgrind on my openWRT, ARMV7 machine, and tried to use it in the following manner: Which version of vagrind? Run "valgrind --version". Which version of openWRT? And from what source (linux distribution, web page, download location, etc.)? > > valgrind --leak-check=yes <application name> > > in return, I got the following response: > > ==1517== Invalid read of size 4 > ==1517== at 0x48C1950: ??? (in /lib/libuClibc-0.9.33.2.so <http://0.9.33.2.so>) > ==1517== Address 0xbdb60c1c is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes > > > The same case happen with any other application I've tried to run. > It seems to me that I have some low-level configuration issue, but I couldn't find it. It's not a configuration issue. It is a bug in the code for libuClibc-0.9.33.2.so or some caller. As the message indicates, gcc-2.96 often generated such bugs. (gcc-2.96 is a *very* old compiler), although hand-generated assembly code (such as in very early library initialization) also can have such a bug. Please show the complete error message paragraph, including all traceback lines, from valgrind(memcheck). Please be sure to install any debuginfo that is available for libuClibc-0.9.33.2.so. Please remember to compile and link your app with "-g" (in order to generate debugging information), and do not remove or strip the symbols from the executable. Add the command-line parameters "--track-origins=yes --vgdb-error=0" to the invocation of valgrind. Open another terminal window and follow the directions on running gdb. When valgrind's complaint appears, then get more information from gdb: (gdb) bt # backtrace of subroutine calls (gdb) info reg # register contents (gdb) x/8i $pc-4*4 # instruction stream -- |
|
From: John R. <jr...@bi...> - 2015-08-06 02:58:54
|
> I installed Valgrind on my openWRT, ARMV7 machine, ... > 1. Valgrind version is 3.10.1 > 2. OpenWRT version is Barrier Breaker, linux distribution > **************** > root@OpenWrt:/# valgrind --leak-check=yes --workaround-gcc296-bugs=yes ./usr/bin/cm > ==1514== Memcheck, a memory error detector > ==1514== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==1514== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info > ==1514== Command: ./usr/bin/cm > ==1514== > ==1514== Conditional jump or move depends on uninitialised value(s) > ==1514== at 0x49DF018: ??? (in /lib/libuClibc-0.9.33.2.so <http://libuClibc-0.9.33.2.so>) Please try my other suggestion (from a previous response): > Add the command-line parameter "--vgdb-error=0" > to the invocation of valgrind. Open another terminal window > and follow the directions on running gdb. When valgrind's complaint > appears, then get more information from gdb: > (gdb) bt # backtrace of subroutine calls > (gdb) info reg # register contents > (gdb) x/8i $pc-4*4 # instruction stream In particular, the "info reg" may tell us that the assembly language code (whether generated by compiler or a human) is referencing memory on the wrong side of the stack pointer. The "--workaround-gcc296-bugs=yes" tells valgrind(memcheck) not to complain about the *memory access* itself (neither read nor write), but any *value fetched* is of course uninitialized: even a preceding store could have been clobbered by a signal handler. I suspect that is the cause of the message quoted above. Did you say earlier that similar complaints were reported regardless of which application is being checked by memcheck? Do the complaints appear when checking /bin/date ? If so, then it may be reasonable to suppress those complaints; read the documentation! [And if gcc-2.96 really *is* the version that compiled libuClibc-0.9.33.2.so then you should complain to the distributor for causing such pain to developers. Suggest a cross-compiler running on x86_64 using a recent version of gcc or clang. -- |