[Valgrind-users] Valgrind can't find strcmp in ld.so

2016-09-22 Thread Mikhail Baikov
Hello.

I need some help. I want to start valgrind but get this error.

# /mnt/nfs/bin/valgrind/bin/valgrind ls
==933== Memcheck, a memory error detector
==933== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==933== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==933== Command: ls
==933==

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:  strcmp
valgrind:  in an object with soname matching: ld-linux-armhf.so.3
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-armhf.so.3

libc.so and ld.so aren't stripped

$ file ld-2.18-2013.10.so
ld-2.18-2013.10.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 
(SYSV), dynamically linked, not stripped
$ file libc-2.18-2013.10.so
libc-2.18-2013.10.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 
(SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for 
GNU/Linux 2.6.16, not stripped

And I do not see any mentions about strcmp in ld.so but I see it libc.so

# readelf -a /lib/libc.so.6 | grep strcmp
   2069: 00059bf122 FUNCGLOBAL DEFAULT   12 strcmp@@GLIBC_2.4
# readelf -a /lib/ld-linux-armhf.so.3 | grep strcmp


How can I make valgrind work?

-- 
Sincerely
Mihail Baikov


--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


Re: [Valgrind-users] Valgrind doesn't create readable core dumps

2015-07-28 Thread Mikhail Baikov

Hello

I see that gdb can't find general purpose registers.
/warning: Couldn't find general-purpose registers in core file.//

/Maybe valgrind adds these registers with some wrong offset?

On 07/14/2015 04:52 PM, Mikhail Baikov wrote:

Architecture is mipsel. OS is Linux.
the output of uname -a is
Linux 192.168.23.55 3.3.8-3.3 #1 SMP Fri Jul 10 10:11:31 MSK 2015 mips 
GNU/Linux



On 07/13/2015 08:28 PM, Ivo Raisr wrote:



2015-07-13 19:17 GMT+02:00 Mikhail Baikov 
mikhail.bai...@dev.zodiac.tv mailto:mikhail.bai...@dev.zodiac.tv:


Hello.
Is there a possibility to disable signals handling by valgrind?
The core will be created by the system and that will solve the
problem.


This is not an option.
Run of your program (guest) is simulated by Valgrind (host).
Therefore Valgrind itself must create the guest coredump;
operating system can only create coredump of Valgrind (host).

What is your OS and architecture (for example x86/Linux)?

I.


On 07/02/2015 04:11 PM, Mikhail Baikov wrote:

Hello

I've got a problem while reading dumps created by valgrind. I've
compiled and run this code with valgrind and without it.
/int main()//
//{//
//const char *str = segfault;//
//*(char *)str = 'a';//
//return 1;//
//}
/

When I read the system created core dump it's readable
/Core was generated by `./seg'.//
//Program terminated with signal 11, Segmentation fault.//
//#0  0x004006d0 in main () at ./seg.c:4/

When I try to read the core dump created by valgrind, gdb is
unable to read it
/warning: Couldn't find general-purpose registers in core file.//
//
//warning: Could not load shared library symbols for 5
libraries, e.g.
/bin/valgrind/lib/valgrind/vgpreload_core-mips32-linux.so.//
//Use the info sharedlibrary command to see the complete
listing.//
//Do you need set solib-search-path or set sysroot?//
//Core was generated by `'.//
//
//warning: Couldn't find general-purpose registers in core file.//
//../../gdb-7.3.1/gdb/frame-unwind.c:133: internal-error:
frame_unwind_find_by_frame failed//
//A problem internal to GDB has been detected,//
//further debugging may prove unreliable./





--
Sincerely
Mikhail Baikov


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


--
Sincerely
Mikhail Baikov

--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


Re: [Valgrind-users] Valgrind doesn't create readable core dumps

2015-07-13 Thread Mikhail Baikov

Hello.
Is there a possibility to disable signals handling by valgrind? The core 
will be created by the system and that will solve the problem.


On 07/02/2015 04:11 PM, Mikhail Baikov wrote:

Hello

I've got a problem while reading dumps created by valgrind. I've 
compiled and run this code with valgrind and without it.

/int main()//
//{//
//const char *str = segfault;//
//*(char *)str = 'a';//
//return 1;//
//}
/

When I read the system created core dump it's readable
/Core was generated by `./seg'.//
//Program terminated with signal 11, Segmentation fault.//
//#0  0x004006d0 in main () at ./seg.c:4/

When I try to read the core dump created by valgrind, gdb is unable to 
read it

/warning: Couldn't find general-purpose registers in core file.//
//
//warning: Could not load shared library symbols for 5 libraries, e.g. 
/bin/valgrind/lib/valgrind/vgpreload_core-mips32-linux.so.//

//Use the info sharedlibrary command to see the complete listing.//
//Do you need set solib-search-path or set sysroot?//
//Core was generated by `'.//
//
//warning: Couldn't find general-purpose registers in core file.//
//../../gdb-7.3.1/gdb/frame-unwind.c:133: internal-error: 
frame_unwind_find_by_frame failed//

//A problem internal to GDB has been detected,//
//further debugging may prove unreliable./

Can you help me with this?
P.S.
cpu model: Broadcom BMIPS5000 V1.1  FPU V0.1
valgrind-3.10.1

--
Sincerely
Mikhail Baikov


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


--
Sincerely
Mikhail Baikov

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


[Valgrind-users] Valgrind doesn't create readable core dumps

2015-07-02 Thread Mikhail Baikov

Hello

I've got a problem while reading dumps created by valgrind. I've 
compiled and run this code with valgrind and without it.

/int main()//
//{//
//const char *str = segfault;//
//*(char *)str = 'a';//
//return 1;//
//}
/

When I read the system created core dump it's readable
/Core was generated by `./seg'.//
//Program terminated with signal 11, Segmentation fault.//
//#0  0x004006d0 in main () at ./seg.c:4/

When I try to read the core dump created by valgrind, gdb is unable to 
read it

/warning: Couldn't find general-purpose registers in core file.//
//
//warning: Could not load shared library symbols for 5 libraries, e.g. 
/bin/valgrind/lib/valgrind/vgpreload_core-mips32-linux.so.//

//Use the info sharedlibrary command to see the complete listing.//
//Do you need set solib-search-path or set sysroot?//
//Core was generated by `'.//
//
//warning: Couldn't find general-purpose registers in core file.//
//../../gdb-7.3.1/gdb/frame-unwind.c:133: internal-error: 
frame_unwind_find_by_frame failed//

//A problem internal to GDB has been detected,//
//further debugging may prove unreliable./

Can you help me with this?
P.S.
cpu model: Broadcom BMIPS5000 V1.1  FPU V0.1
valgrind-3.10.1

--
Sincerely
Mikhail Baikov

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


Re: [Valgrind-users] Problem running even simple programs

2014-12-11 Thread Mikhail Baikov

On 12/05/2014 09:26 PM, Philippe Waroquiers wrote:
 On Thu, 2014-12-04 at 16:16 +0300, Mikhail Baikov wrote:

 And the crash... I'm sorry it's not a segfault. It's a crash.
 One of the strange things is that inspite of --run-libc-freeres set no
 in the log appears
 /bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest...
 This is I suppose because valgrind has not been properly compiled
 for ulibc.
 If you look in coregrind/vg_preloaded.c, you will see that if symbol
 __UCLIBC__ is defined, then no calls to __libc_freeres();
 will be generated.
 So, that looks a first problem to solve : I guess you should
 ensure that  __UCLIBC__ is defined when you compile on the host,
 and ensure to compile with the relevant uclibc headers files at
 the host side.


Yeah. Raising __UCLIBC__ flag (export CFLAGS=-D__UCLIBC__) has helped 
but it seems to me that this flag will never be raised in normal 
conditions. Searching this flag among sources I found no place where 
it's defined.
$ grep -R __UCLIBC__ ./valgrind-3.10.1/*
./valgrind-3.10.1/coregrind/vg_preloaded.c:#  if !defined(__UCLIBC__) \
./valgrind-3.10.1/coregrind/m_debuginfo/minilzo-inl.c:#elif 
defined(__UCLIBC__)  defined(__UCLIBC_MAJOR__)  
defined(__UCLIBC_MINOR__)
./valgrind-3.10.1/coregrind/m_debuginfo/lzodefs.h:#elif 
defined(__UCLIBC__)  defined(__UCLIBC_MAJOR__)  
defined(__UCLIBC_MINOR__)


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


Re: [Valgrind-users] Problem running even simple programs

2014-12-04 Thread Mikhail Baikov

On 12/04/2014 12:44 AM, Philippe Waroquiers wrote:
 Then I might have missed something in the mail exchanges.

 Your initial mail said that the bug is valgrind fails to find
 problems even in simple applications.
 The example shown was with /bin/true. This was reporting 'invalid read
 errors' originating from ulibc loader.
 This I guess can be fixed by having a ulibc.supp file.

 So, what is the segfault in a bigger application ?

 Philippe



The bigger application starts from valgrind with verbose debugging.

==2633== Command: ./nexus ./supervisor ./powerup-launcher
==2633==
--2633-- Valgrind options:
--2633---v
--2633---v
--2633---v
--2633---d
--2633---d
--2633---d
--2633----run-libc-freeres=no
--2633----suppressions=/bin/mbaikov/uclibc.supp
--2633----trace-children=yes
--2633----workaround-gcc296-bugs=yes

And the crash... I'm sorry it's not a segfault. It's a crash.
One of the strange things is that inspite of --run-libc-freeres set no 
in the log appears
/bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest... I 
have no idea what exactly to show

==2633== Adding active redirection:
--2633-- new: 0x048965d0 (valloc  ) R- (1012.0) 
0x0481ea98 valloc
--2633:2:transtab   discard_translations(0x4896734, 1) req by 
redir_new_DebugInfo(from_addr)
--2633:2:transtab   FAST, ec = 44
--2633:2:transtab   discard_translations(0x481ea00, 1) req by 
redir_new_DebugInfo(to_addr)
--2633:2:transtab   FAST, ec = 61
==2633== Adding active redirection:
--2633-- new: 0x04896734 (posix_memalign  ) R- (1016.0) 
0x0481ea00 posix_memalign

/bin/sh: symbol '__libc_freeres': can't resolve symbol
--2633:1:syswrap- thread_wrapper(tid=1): exit, schedreturncode 
VgSrc_ExitThread
--2633:1:syswrap- run_a_thread_NORETURN(tid=1): post-thread_wrapper
--2633:1:syswrap- run_a_thread_NORETURN(tid=1): last one standing
--2633:1:main entering VG_(shutdown_actions_NORETURN)
--2633:1:aspacem   SHOW_SEGMENTS: Memory layout at client shutdown 
(57 segments, 9 segnames)
--2633:1:aspacem  ( 0) 
/bin/mbaikov/valgrind_arm/lib/valgrind/memcheck-arm-linux
--2633:1:aspacem  ( 1) /bin/bash
--2633:1:aspacem  ( 2) /lib/ld-uClibc-0.9.32.1.so
--2633:1:aspacem  ( 3) /tmp/vgdb-pipe-shared-mem-vgdb-2633-by-root-on-???
--2633:1:aspacem  ( 4) 
/bin/mbaikov/valgrind_arm/lib/valgrind/vgpreload_core-arm-linux.so
--2633:1:aspacem  ( 5) 
/bin/mbaikov/valgrind_arm/lib/valgrind/vgpreload_memcheck-arm-linux.so
--2633:1:aspacem  ( 6) /lib/libdl-0.9.32.1.so
--2633:1:aspacem  ( 7) /lib/libgcc_s.so.1
--2633:1:aspacem  ( 8) /lib/libuClibc-0.9.32.1.so
--2633:1:aspacem0: RSVN 00-007fff   32768 - SmFixed
--2633:1:aspacem1: file 008000-0a0fff  626688 r-x-- d=0x00c 
i=6174178 o=0   (1)
--2633:1:aspacem2: RSVN 0a1000-0a7fff   28672 - SmFixed
--2633:1:aspacem3: file 0a8000-0acfff   20480 rw--- d=0x00c 
i=6174178 o=622592  (1)
--2633:1:aspacem4: anon 0ad000-0b1fff   20480 rw---
--2633:1:aspacem5: RSVN 0b2000-0003ff 63m - SmFixed
--2633:1:aspacem6: file 000400-0004008fff   36864 r-xT- d=0x00c 
i=6160505 o=0   (2)
--2633:1:aspacem7: anon 0004009000-000400afff8192 rw---
--2633:1:aspacem8:  000400b000-000400   20480
--2633:1:aspacem9: file 000401-0004011fff8192 rw--- d=0x00c 
i=6160505 o=32768   (2)
--2633:1:aspacem   10: anon 0004012000-0004012fff4096 rwx--
--2633:1:aspacem   11: RSVN 0004013000-0004811fff 8384512 - SmLower
--2633:1:aspacem   12: file 0004812000-0004812fff4096 r-x-- d=0x00c 
i=6948052 o=0   (4)
--2633:1:aspacem   13: anon 0004813000-0004819fff   28672 -
--2633:1:aspacem   14: file 000481a000-000481afff4096 rw--- d=0x00c 
i=6948052 o=0   (4)
--2633:1:aspacem   15: file 000481b000-0004827fff   53248 r-x-- d=0x00c 
i=6948058 o=0   (5)
--2633:1:aspacem   16: anon 0004828000-000482efff   28672 -
--2633:1:aspacem   17: file 000482f000-0004824096 rw--- d=0x00c 
i=6948058 o=49152   (5)
--2633:1:aspacem   18: file 000483-0004832fff   12288 r-x-- d=0x00c 
i=6160501 o=0   (6)
--2633:1:aspacem   19: anon 0004833000-0004839fff   28672 -
--2633:1:aspacem   20: file 000483a000-000483bfff8192 rw--- d=0x00c 
i=6160501 o=8192(6)
--2633:1:aspacem   21: file 000483c000-0004845fff   40960 r-x-- d=0x00c 
i=6160503 o=0   (7)
--2633:1:aspacem   22: anon 0004846000-000484cfff   28672 -
--2633:1:aspacem   23: file 000484d000-000484dfff4096 rw--- d=0x00c 
i=6160503 o=36864   (7)
--2633:1:aspacem   24: file 000484e000-00048d5fff  557056 r-x-- d=0x00c 
i=6160509 o=0   (8)
--2633:1:aspacem   25: anon 00048d6000-00048dcfff   28672 -
--2633:1:aspacem   26: file 00048dd000-00048defff8192 rw--- d=0x00c 
i=6160509 o=552960  (8)
--2633:1:aspacem   27: anon 00048df000-00048e3fff   20480 rw---
--2633:1:aspacem   28:  00048e4000-0037ff823m

Re: [Valgrind-users] Problem running even simple programs

2014-12-03 Thread Mikhail Baikov

 On Thu, 2014-11-27 at 23:06 +0300, Mikhail Baikov wrote:

 ==1654== Invalid read of size 4
 ==1654==at 0x489B248: __uClibc_main (in /lib/libuClibc-0.9.32.1.so)
 ==1654==  Address 0xbdd74b44 is on thread 1's stack
 ==1654==  20 bytes below stack pointer
 ==1654==
 I also have
 # valgrind -v -v -v -d -d -d --trace-redir=yes /bin/true
 log but it's really big to attach it here.

 And i really can't understand where is the problem because I tried to
 build trunk valgring (which fails with the same errors), tried 3.10.0
 with patches from buildroot with the same result.

 And now I don't know where to dig.
 A possible cause of the above problem is that valgrind does
 not recognise the name of the uClibc dynamic loader.
 There is some code that handles specially the dynamic loader.
 See coregrind/m_redir.c line 1363 for the expected names on arm
 or some similar names in include/pub_tool_redir.h
In include/pub_tool_redir.h there is a
#  define  VG_Z_LIBC_SONAME  libcZdsoZa  // libc.so*
that corresponds with what I have in my /lib directory
ls -la /lib/libc.so.0
lrwxrwxrwx1 root root21 Nov 18  2014 /lib/libc.so.0 
- libuClibc-0.9.32.1.so
# readelf -a /lib/libuClibc-0.9.32.1.so | grep soname
  0x000e (SONAME) Library soname: [libc.so.0]

In coregrind/m_redir.c there are two ld-linux.so.3 and 
ld-linux-armhf.so.3 loader names. If I add ld-uClibc.so.0 loader, 
rebuild valgrind and try to run any binary i get this kind of error

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:  strcmp
valgrind:  in an object with soname matching:   ld-uClibc.so.0
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-uClibc.so.0

 It might also just be normal errors, that are suppressed
 by the standard valgrind suppression files, but that in your
 case are not matching due to the uClibc use ?
 See e.g. default.supp (generated from various *.supp files).
 I see no uclibc specific files there, which makes me believe
 valgrind is not (yet) fine tuned to be used with uclibc.

 For what concerns the error message
 /bin/true: can't resolve symbol '__libc_freeres'
 again that is probably caused by uClib, which I guess does not
 provide __libc_freeres
 To avoid this msg, you can use --run-libc-freeres=no
I've taken uclibc.supp from buildroot and added suppression option with 
it but it hasn't helped.
 Note however that I see in coregrind/vg_preloaded.c (line 59)
 that the call should not be done when valgrind is compiled
 for UCLIBC.
 So, might be good to verify how e.g. vg_preloaded.c was
 compiled.
gcc -v of the toolchain i've been given is
./arm-linux-uclibcgnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=./arm-linux-uclibcgnueabi-gcc
COLLECT_LTO_WRAPPER=/home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.5.4/lto-wrapper
Target: arm-linux-uclibcgnueabi
Configured with: ../gcc-4.5.4/configure --target=arm-linux-uclibcgnueabi 
--enable-multilib 
--prefix=/usr/src/redhat/BUILD/build-toolchain//opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp
 
--with-local-prefix=/usr/src/redhat/BUILD/build-toolchain//opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/arm-linux-uclibcgnueabi/sys-root
 
--with-sysroot=/usr/src/redhat/BUILD/build-toolchain//opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/arm-linux-uclibcgnueabi/sys-root
 
--enable-threads=posix --enable-long-long --enable-c99 
--enable-__cxa_atexit --with-gmp=/usr/src/redhat/BUILD/prereq 
--with-mpfr=/usr/src/redhat/BUILD/prereq 
--with-mpc=/usr/src/redhat/BUILD/prereq 
--with-libelf=/usr/src/redhat/BUILD/prereq --disable-nls 
--enable-symvers=gnu --enable-languages=c,c++ --enable-target-optspace 
--with-pkgversion='Broadcom stbgcc-4.5.4-2.7_uclibc_ssp' 
--with-host-libstdcxx='-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' 
--with-float=soft
Thread model: posix
gcc version 4.5.4 (Broadcom stbgcc-4.5.4-2.7_uclibc_ssp)

The single line where I see something about vg_preloaded.c is
  
/home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.5.4/cc1
 -quiet -v -I. -I.. -I.. -I../include -I../VEX/pub -I../VEX/pub -I../coregrind 
-iprefix 
/home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.5.4/
 -isysroot 
/home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../arm-linux-uclibcgnueabi/sys-root
 -MD vgpreload_core_arm_linux_so-vg_preloaded.d -MF 
.deps/vgpreload_core_arm_linux_so-vg_preloaded.Tpo -MP -MT 
vgpreload_core_arm_linux_so-vg_preloaded.o -DHAVE_CONFIG_H -DVGA_arm=1 
-DVGO_linux=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_vanilla=1

[Valgrind-users] Problem running even simple programs

2014-11-27 Thread Mikhail Baikov
Hello
I built valgrind 3.10.1 for arm platform (on amd64 host system) and got 
a problem. Memcheck fails finding problems even in /bin/true

# valgrind /bin/true
==1654== Memcheck, a memory error detector
==1654== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1654== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==1654== Command: /bin/true
==1654==
==1654== Invalid read of size 4
==1654==at 0x40071B0: _dl_get_ready_to_run (in 
/lib/ld-uClibc-0.9.32.1.so)
==1654==  Address 0xbdd749d4 is on thread 1's stack
==1654==  20 bytes below stack pointer
==1654==
==1654== Invalid read of size 4
==1654==at 0x489B248: __uClibc_main (in /lib/libuClibc-0.9.32.1.so)
==1654==  Address 0xbdd74b44 is on thread 1's stack
==1654==  20 bytes below stack pointer
==1654==
==1654== Invalid read of size 4
==1654==at 0x489B02C: __uClibc_fini (in /lib/libuClibc-0.9.32.1.so)
==1654==  Address 0xbdd74aec is on thread 1's stack
==1654==  20 bytes below stack pointer
==1654==
==1654== Invalid read of size 4
==1654==at 0x4002324: ??? (in /lib/ld-uClibc-0.9.32.1.so)
==1654==  Address 0xbdd74ab4 is on thread 1's stack
==1654==  20 bytes below stack pointer
==1654==
/bin/true: can't resolve symbol '__libc_freeres'
==1654==
==1654== HEAP SUMMARY:
==1654== in use at exit: 0 bytes in 0 blocks
==1654==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1654==
==1654== All heap blocks were freed -- no leaks are possible
==1654==
==1654== For counts of detected and suppressed errors, rerun with: -v
==1654== ERROR SUMMARY: 48 errors from 4 contexts (suppressed: 0 from 0)

I also have
# valgrind -v -v -v -d -d -d --trace-redir=yes /bin/true
log but it's really big to attach it here.

And i really can't understand where is the problem because I tried to 
build trunk valgring (which fails with the same errors), tried 3.10.0 
with patches from buildroot with the same result.

And now I don't know where to dig.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users