Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(9) |
Sep
(1) |
Oct
(7) |
Nov
(1) |
Dec
|
|
From: Philippe W. <phi...@sk...> - 2013-11-18 22:55:19
|
On Mon, 2013-11-18 at 11:40 +0100, Benjamin Schindler wrote:
> Hi
>
> I just upgraded to valgrind 3.9.0 (debian sid backport). Most features
> work, but helgrind hangs with my application, and starts to fill up
> memory until the system starts swapping badly. This did not happen with
> 3.8. I tried with and without the suppressions file I'm using but that
> doesn't help.
> The only thing that might be an issue is that the application uses cuda
> and helgrind used to throw a lot of errors concerning cuda (all of which
> I dealt with using a suppression file)
>
> Is this something known or is there a way I can debug this further?
You can try several things to get more info about what is going on:
* run with --profile-heap=yes
This will regularly provide details about who allocates what
* together with the above, you can also use gdb+vgdb to debug
your app running under valgrind, and use
monitor v.info memory aspacemgr
to get memory details at selected places.
It might be interesting to do the above with 3.8.1 and 3.9 and look at
the differences.
Note that in 3.9.0, several arenas (kind of memory
zones of the valgrind allocator) have been merged together.
Philippe
|
|
From: Benjamin S. <bsc...@vr...> - 2013-11-18 10:42:03
|
Hi I just upgraded to valgrind 3.9.0 (debian sid backport). Most features work, but helgrind hangs with my application, and starts to fill up memory until the system starts swapping badly. This did not happen with 3.8. I tried with and without the suppressions file I'm using but that doesn't help. The only thing that might be an issue is that the application uses cuda and helgrind used to throw a lot of errors concerning cuda (all of which I dealt with using a suppression file) Is this something known or is there a way I can debug this further? Thank you Benjamin Schindler -- Dr. Benjamin Schindler, Software Developer VRVis Forschungs-GmbH, www.VRVis.at FN, 195369h, HG Wien mail: bsc...@vr..., tel +43(0)1 20501 30803 |
|
From: Miguel G. <mig...@gm...> - 2013-11-15 17:40:16
|
Hello List, I'm seeing lots of reports similar to the ones attached below when I run valgrind on my project. The code seems to be sound because when I don't dlopen a shared library, no reports are output. Also, I'm unsure if it is relevant but my project uses boost. What, in your opinion, is causing valgrind to report the (non-)issues below? And, if it is indeed valgrind at fault here, are there any special measures I can take so as to ensure valgrind runs correctly? ================= ==20245== Invalid read of size 4 ==20245== at 0x58E064D: ??? (in /usr/lib/x86_64-linux-gnu/libstdc+ +.so.6.0.18) ==20245== by 0x593F05E: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() (in /usr/ lib/x86_64-linux-gnu/libstdc++.so.6.0.18) ==20245== by 0x5DDB070: __run_exit_handlers (exit.c:77) ==20245== by 0x5DDB0F4: exit (exit.c:99) ==20245== by 0x5DC0DEB: (below main) (libc-start.c:294) ==20245== Address 0x6688980 is 16 bytes inside a block of size 39 free'd ==20245== at 0x4C2BADC: operator delete(void*) (in /usr/lib/valgrind/ vgpreload_memcheck-amd64-linux.so) ==20245== by 0x593F05E: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() (in /usr/ lib/x86_64-linux-gnu/libstdc++.so.6.0.18) ==20245== by 0x5DDB479: __cxa_finalize (cxa_finalize.c:55) ==20245== by 0x7467BF2: ??? ==20245== by 0x4014BCE: _dl_close_worker (dl-close.c:266) ==20245== by 0x401569D: _dl_close (dl-close.c:776) ==20245== by 0x400F6E5: _dl_catch_error (dl-error.c:177) ==20245== by 0x568263B: _dlerror_run (dlerror.c:163) ==20245== by 0x568210E: dlclose (dlclose.c:47) ==20245== by 0x50A22E: omnis::transform::Collection::~Collection() (transform_collection.cxx:47) ==20245== by 0x4EDAE8: OmnisApp::run(int, char**) (omnis_app.cxx:107) ==20245== by 0x4EE25D: main (main.cxx:16) ==20245== ==20245== Invalid free() / delete / delete[] / realloc() ==20245== at 0x4C2BADC: operator delete(void*) (in /usr/lib/valgrind/ vgpreload_memcheck-amd64-linux.so) ==20245== by 0x593F05E: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() (in /usr/ lib/x86_64-linux-gnu/libstdc++.so.6.0.18) ==20245== by 0x5DDB070: __run_exit_handlers (exit.c:77) ==20245== by 0x5DDB0F4: exit (exit.c:99) ==20245== by 0x5DC0DEB: (below main) (libc-start.c:294) ==20245== Address 0x6688970 is 0 bytes inside a block of size 39 free'd ==20245== at 0x4C2BADC: operator delete(void*) (in /usr/lib/valgrind/ vgpreload_memcheck-amd64-linux.so) ==20245== by 0x593F05E: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() (in /usr/ lib/x86_64-linux-gnu/libstdc++.so.6.0.18) ==20245== by 0x5DDB479: __cxa_finalize (cxa_finalize.c:55) ==20245== by 0x7467BF2: ??? ==20245== by 0x4014BCE: _dl_close_worker (dl-close.c:266) ==20245== by 0x401569D: _dl_close (dl-close.c:776) ==20245== by 0x400F6E5: _dl_catch_error (dl-error.c:177) ==20245== by 0x568263B: _dlerror_run (dlerror.c:163) ==20245== by 0x568210E: dlclose (dlclose.c:47) ==20245== by 0x50A22E: omnis::transform::Collection::~Collection() (transform_collection.cxx:47) ==20245== by 0x4EDAE8: OmnisApp::run(int, char**) (omnis_app.cxx:107) ==20245== by 0x4EE25D: main (main.cxx:16) |
|
From: Philippe W. <phi...@sk...> - 2013-11-13 21:27:59
|
On Mon, 2013-11-11 at 03:07 +0000, Jun Yuan wrote: > Hello, > > >From what I understand about the document, I will have to put > LD_PRELOAD=/pathtowrapper/libwrapper.so before launching valgrind through > "exec /data/local/Inst/bin/valgrind $VALPARAMS $*". My question is, I suppose > I will have to compile my wrapper.c using the exact same configuration used > to build valgrind-- the NDK compiler, NDK linker, etc -- am I correct? I only > used wrapper on my laptop linux-x86, not sure how different they would be. > > Thanks for any input! > > -Jun I do not think it is mandatory have wrappers function in a LD_PRELOADed .so file. I think you can write a wrapper function in your "main" executable, statically linked. See e.g. memcheck/tests/wrap1.c as an example. Philippe |
|
From: Phil L. <plo...@sa...> - 2013-11-11 20:48:11
|
I have a question about helgrind and lock order reversals. Does helgrind check whether multiple threads are involved, or can I have an LOR report if I have one thread which sometimes locks in one order, and sometimes locks in another? Phil |
|
From: miguel b. <mig...@ho...> - 2013-11-11 12:53:11
|
Im trying to cross-compile valgrind for MIPS architecture but im getting errors:
$ ./configure --host=mips-linux-uclibc CC="/toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-gcc" CXX="/toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-g++" AR="/toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-ar" RANLIB="/toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-ar" STRIP="/toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-strip"
configure: WARNING: if you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mips-linux-uclibc-strip... /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether ln -s works... yes
checking for mips-linux-uclibc-gcc... /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-gcc accepts -g... yes
checking for /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-gcc... gcc3
checking whether /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-gcc -E
checking whether we are using the GNU C++ compiler... yes
checking whether /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-g++ accepts -g... yes
checking dependency style of /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-g++... gcc3
checking for mips-linux-uclibc-ranlib... /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-ar
checking for a sed that does not truncate output... /bin/sed
checking for perl... /usr/bin/perl
checking for gdb... /usr/bin/gdb
checking dependency style of /toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-gcc... gcc3
checking for diff -u... yes
checking for a supported version of gcc... ok (4.4.6)
checking build system type... x86_64-unknown-linux-gnu
checking host system type... mips-unknown-linux-uclibc
checking for a supported CPU... ok (mips)
checking for a 64-bit only build... no
checking for a 32-bit only build... no
checking for a supported OS... ok (linux-uclibc)
checking for the kernel version... 2.6.x/3.x family (3.5.0-41-generic)
checking for a supported CPU/OS combination... ok (mips32-linux)
checking for use as an inner Valgrind... no
checking for Pagesize... 4k
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking features.h usability... yes
checking features.h presence... yes
checking for features.h... yes
checking the GLIBC_VERSION version... 2.2 family
checking for AT_FDCWD... yes
checking for stpncpy... yes
checking for PTRACE_GETREGS... yes
checking for CLOCK_MONOTONIC... yes
checking for pthread_rwlock_t... yes
checking for PTHREAD_MUTEX_ADAPTIVE_NP... yes
checking for PTHREAD_MUTEX_ERRORCHECK_NP... yes
checking for PTHREAD_MUTEX_RECURSIVE_NP... yes
checking for PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP... yes
checking for pthread_mutex_t.__m_kind... yes
checking for pthread_mutex_t.__data.__kind... no
checking for Altivec... no
checking for VSX... no
checking that assembler knows DFP... no
checking that compiler knows -mhard-dfp switch... no
checking that compiler knows DFP datatypes... no
checking that assembler knows ISA 2.07 ... no
checking for pthread_create@GLIBC2.0()... no
checking for eventfd()... no
checking that C++ compiler can include <thread> header file... yes
checking if gcc accepts -m32... no
checking if gcc accepts -m64... no
checking if gcc accepts -mmmx... no
checking if gcc accepts -msse... no
checking if gcc accepts -mpreferred-stack-boundary... no
checking if gcc accepts -Wno-pointer-sign... yes
checking if gcc accepts -Wwrite-strings... yes
checking if gcc accepts -Wno-empty-body... yes
checking if gcc accepts -Wno-format-zero-length... yes
checking if gcc accepts -Wno-nonnull... yes
checking if gcc accepts -Wno-overflow... yes
checking if gcc accepts -Wno-uninitialized... yes
checking if gcc accepts -Wextra or -W... -Wextra
checking if gcc accepts -fno-stack-protector... yes
checking if gcc accepts --param inline-unit-growth... yes
checking if gcc accepts -gdwarf-4 -fdebug-types-section... no
checking if gcc accepts -gstabs... yes
checking if gcc accepts nested functions... yes
checking if gcc accepts the 'p' constraint in asm statements... no
checking if the linker accepts -Wl,-Ttext-segment... yes
configure: ld -Ttext-segment used, no need to strip build-id NOTEs.
checking if ppc32/64 as supports mtocrf/mfocrf... no
checking if ppc32/64 asm supports phased out floating point instructions... no
checking if x86/amd64 assembler speaks SSE3... no
checking if x86/amd64 assembler speaks SSSE3... no
checking if x86/amd64 assembler supports 'pclmulqdq'... no
checking if x86/amd64 assembler supports 'vpclmulqdq'... no
checking if x86/amd64 assembler supports 'lzcnt'... no
checking if x86/amd64 assembler supports 'loopnel'... no
checking if x86/amd64 assembler supports 'addr32'... no
checking if x86/amd64 assembler speaks SSE4.2... no
checking if x86/amd64 assembler speaks AVX... no
checking if x86/amd64 assembler speaks AVX2... no
checking if x86/amd64 assembler speaks TSX... no
checking if x86/amd64 assembler speaks BMI1 and BMI2... no
checking if x86/amd64 assembler speaks FMA... no
checking if x86/amd64 assembler knows the MOVBE insn... no
checking if gcc supports the ifunc attribute... no
checking for TLS support... yes
checking for ANSI C header files... (cached) yes
checking asm/unistd.h usability... yes
checking asm/unistd.h presence... yes
checking for asm/unistd.h... yes
checking endian.h usability... yes
checking endian.h presence... yes
checking for endian.h... yes
checking mqueue.h usability... yes
checking mqueue.h presence... yes
checking for mqueue.h... yes
checking sys/endian.h usability... no
checking sys/endian.h presence... no
checking for sys/endian.h... no
checking sys/epoll.h usability... yes
checking sys/epoll.h presence... yes
checking for sys/epoll.h... yes
checking sys/eventfd.h usability... no
checking sys/eventfd.h presence... no
checking for sys/eventfd.h... no
checking sys/klog.h usability... yes
checking sys/klog.h presence... yes
checking for sys/klog.h... yes
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking sys/signal.h usability... yes
checking sys/signal.h presence... yes
checking for sys/signal.h... yes
checking sys/signalfd.h usability... yes
checking sys/signalfd.h presence... yes
checking for sys/signalfd.h... yes
checking sys/syscall.h usability... yes
checking sys/syscall.h presence... yes
checking for sys/syscall.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for sys/types.h... (cached) yes
checking if <linux/futex.h> is usable... yes
checking for uid_t in sys/types.h... yes
checking for off_t... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for working memcmp... no
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... no
checking for pthread_create in -lpthread... yes
checking for clock_gettime in -lrt... yes
checking for clock_gettime... yes
checking for epoll_create... yes
checking for epoll_pwait... no
checking for klogctl... yes
checking for mallinfo... yes
checking for memchr... yes
checking for memset... yes
checking for mkdir... yes
checking for mremap... yes
checking for ppoll... yes
checking for pthread_barrier_init... yes
checking for pthread_condattr_setclock... no
checking for pthread_mutex_timedlock... yes
checking for pthread_rwlock_timedrdlock... yes
checking for pthread_rwlock_timedwrlock... yes
checking for pthread_spin_lock... yes
checking for pthread_yield... no
checking for pthread_setname_np... no
checking for readlinkat... yes
checking for semtimedop... yes
checking for signalfd... yes
checking for sigwaitinfo... yes
checking for strchr... yes
checking for strdup... yes
checking for strpbrk... yes
checking for strrchr... yes
checking for strstr... yes
checking for syscall... yes
checking for utimensat... yes
checking for process_vm_readv... no
checking for process_vm_writev... no
checking primary target for usable MPI2-compliant C compiler and mpi.h... no
checking secondary target for usable MPI2-compliant C compiler and mpi.h... no
checking for boost... no
checking for OpenMP... no
checking if gcc supports __sync_add_and_fetch for the primary target... no
checking if gcc supports __sync_add_and_fetch on uint64_t for all targets... no
checking if g++ supports __sync_add_and_fetch... no
checking if libstdc++ supports annotating shared pointers... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating VEX/Makefile
config.status: creating valgrind.spec
config.status: creating valgrind.pc
config.status: creating glibc-2.X.supp
config.status: creating docs/Makefile
config.status: creating tests/Makefile
config.status: creating tests/vg_regtest
config.status: creating perf/Makefile
config.status: creating perf/vg_perf
config.status: creating gdbserver_tests/Makefile
config.status: creating include/Makefile
config.status: creating auxprogs/Makefile
config.status: creating mpi/Makefile
config.status: creating coregrind/Makefile
config.status: creating memcheck/Makefile
config.status: creating memcheck/tests/Makefile
config.status: creating memcheck/tests/common/Makefile
config.status: creating memcheck/tests/amd64/Makefile
config.status: creating memcheck/tests/x86/Makefile
config.status: creating memcheck/tests/linux/Makefile
config.status: creating memcheck/tests/darwin/Makefile
config.status: creating memcheck/tests/amd64-linux/Makefile
config.status: creating memcheck/tests/x86-linux/Makefile
config.status: creating memcheck/tests/ppc32/Makefile
config.status: creating memcheck/tests/ppc64/Makefile
config.status: creating memcheck/tests/s390x/Makefile
config.status: creating memcheck/tests/vbit-test/Makefile
config.status: creating cachegrind/Makefile
config.status: creating cachegrind/tests/Makefile
config.status: creating cachegrind/tests/x86/Makefile
config.status: creating cachegrind/cg_annotate
config.status: creating cachegrind/cg_diff
config.status: creating callgrind/Makefile
config.status: creating callgrind/callgrind_annotate
config.status: creating callgrind/callgrind_control
config.status: creating callgrind/tests/Makefile
config.status: creating helgrind/Makefile
config.status: creating helgrind/tests/Makefile
config.status: creating massif/Makefile
config.status: creating massif/tests/Makefile
config.status: creating massif/ms_print
config.status: creating lackey/Makefile
config.status: creating lackey/tests/Makefile
config.status: creating none/Makefile
config.status: creating none/tests/Makefile
config.status: creating none/tests/amd64/Makefile
config.status: creating none/tests/ppc32/Makefile
config.status: creating none/tests/ppc64/Makefile
config.status: creating none/tests/x86/Makefile
config.status: creating none/tests/arm/Makefile
config.status: creating none/tests/s390x/Makefile
config.status: creating none/tests/mips32/Makefile
config.status: creating none/tests/mips64/Makefile
config.status: creating none/tests/linux/Makefile
config.status: creating none/tests/darwin/Makefile
config.status: creating none/tests/x86-linux/Makefile
config.status: creating exp-sgcheck/Makefile
config.status: creating exp-sgcheck/tests/Makefile
config.status: creating drd/Makefile
config.status: creating drd/scripts/download-and-build-splash2
config.status: creating drd/tests/Makefile
config.status: creating exp-bbv/Makefile
config.status: creating exp-bbv/tests/Makefile
config.status: creating exp-bbv/tests/x86/Makefile
config.status: creating exp-bbv/tests/x86-linux/Makefile
config.status: creating exp-bbv/tests/amd64-linux/Makefile
config.status: creating exp-bbv/tests/ppc32-linux/Makefile
config.status: creating exp-bbv/tests/arm-linux/Makefile
config.status: creating exp-dhat/Makefile
config.status: creating exp-dhat/tests/Makefile
config.status: creating coregrind/link_tool_exe_linux
config.status: creating coregrind/link_tool_exe_darwin
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
Maximum build arch: mips32
Primary build arch: mips32
Secondary build arch:
Build OS: linux
Primary build target: MIPS32_LINUX
Secondary build target:
Platform variant: vanilla
Primary -DVGPV string: -DVGPV_mips32_linux_vanilla=1
Default supp files: exp-sgcheck.supp xfree-3.supp xfree-4.supp glibc-2.X-drd.supp glibc-2.2-LinuxThreads-helgrind.supp glibc-2.2.supp
$ make
make all-recursive
make[1]: Entering directory `/valgrind-3.9.0'
Making all in include
make[2]: Entering directory `/valgrind-3.9.0/include'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/valgrind-3.9.0/include'
Making all in VEX
make[2]: Entering directory `/valgrind-3.9.0/VEX'
make all-am
make[3]: Entering directory `/valgrind-3.9.0/VEX'
/toolchain/rsdk-1.5.6-5281-EB-2.6.30-0.9.30.3-110915/bin/rsdk-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_mips32=1 -DVGO_linux=1 -DVGP_mips32_linux=1 -DVGPV_mips32_linux_vanilla=1 -Ipriv -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -mips32 -Wbad-function-cast -Wcast-qual -Wcast-align -fstrict-aliasing -Wno-long-long -Wwrite-strings -fno-stack-protector -MT priv/libvex_mips32_linux_a-main_globals.o -MD -MP -MF priv/.deps/libvex_mips32_linux_a-main_globals.Tpo -c -o priv/libvex_mips32_linux_a-main_globals.o `test -f 'priv/main_globals.c' || echo './'`priv/main_globals.c
priv/main_globals.c:1: error: '-mips32' conflicts with the other architecture options, which specify a mips1 processor
make[3]: *** [priv/libvex_mips32_linux_a-main_globals.o] Error 1
make[3]: Leaving directory `/valgrind-3.9.0/VEX'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/valgrind-3.9.0/VEX'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/valgrind-3.9.0'
make: *** [all] Error 2
|
|
From: Jun Y. <YJ...@gm...> - 2013-11-11 03:08:29
|
Hello, >From what I understand about the document, I will have to put LD_PRELOAD=/pathtowrapper/libwrapper.so before launching valgrind through "exec /data/local/Inst/bin/valgrind $VALPARAMS $*". My question is, I suppose I will have to compile my wrapper.c using the exact same configuration used to build valgrind-- the NDK compiler, NDK linker, etc -- am I correct? I only used wrapper on my laptop linux-x86, not sure how different they would be. Thanks for any input! -Jun |
|
From: Saurabh T <sa...@ho...> - 2013-11-08 23:06:24
|
---------------------------------------- > Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy > From: phi...@sk... > To: sa...@ho... > CC: val...@li... > Date: Fri, 8 Nov 2013 22:46:28 +0100 > > I think this is a regression in 3.9.0 caused by revision 13642 which: > Fix #323432: When calling pthread_cond_destroy or pthread_mutex_destroy > with initializers as argument Helgrind (incorrectly) reports errors. > > The problem is that the pthread_mutex_destroy wrapper function is > comparing the mutex with PTHREAD_MUTEX_INITIALIZER to detect if mutex > was initialised using PTHREAD_MUTEX_INITIALIZER > rather than with pthread_mutex_init. Philippe, Thank you for the patch, it worked. For what it's worth, the situation that you mention cannot happen for my code. saurabh > Now, is this really a regression ? It might in fact be a feature :). > > If there is no synchronisation mechanism between a thread doing > lock/unlock and another thread calling pthread_mutex_destroy, then > if the thread doing lock/unlock is slow, the mutex could be destroyed > while it is locked (or even before the locking thread has started to > lock it. And then the locking thread might try to lock a destroyed > mutex. > > Philippe > > |
|
From: Philippe W. <phi...@sk...> - 2013-11-08 21:45:12
|
On Fri, 2013-11-08 at 19:20 +0000, Saurabh T wrote: > ---------------------------------------- > > Date: Fri, 8 Nov 2013 08:20:24 +0100 > > Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy > > From: mag...@gm... > > To: sa...@ho... > > CC: val...@li... > > > > That is most definitely wrong. Thread 1 destroys a locked mutex, and > > according to http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html > > : > >> Attempting to destroy a locked mutex results in undefined behavior. > > > > BR > > Magnus Reftel > > You are right. But I was wrong about what was going on. The mutex *is* destroyed after unlocking. > Sorry. I guess I will put in a suppression for now. I think this is a regression in 3.9.0 caused by revision 13642 which: Fix #323432: When calling pthread_cond_destroy or pthread_mutex_destroy with initializers as argument Helgrind (incorrectly) reports errors. The problem is that the pthread_mutex_destroy wrapper function is comparing the mutex with PTHREAD_MUTEX_INITIALIZER to detect if mutex was initialised using PTHREAD_MUTEX_INITIALIZER rather than with pthread_mutex_init. The regression should be fixed (no test case :) with: Index: helgrind/hg_intercepts.c =================================================================== --- helgrind/hg_intercepts.c (revision 13711) +++ helgrind/hg_intercepts.c (working copy) @@ -470,7 +470,9 @@ PTH_FUNC(int, pthreadZumutexZudestroy, // pthread_ if (mutex != NULL) { static const pthread_mutex_t mutex_init = PTHREAD_MUTEX_INITIALIZER; + VALGRIND_HG_DISABLE_CHECKING(mutex, sizeof(*mutex)); mutex_is_init = my_memcmp(mutex, &mutex_init, sizeof(*mutex)) == 0; + VALGRIND_HG_ENABLE_CHECKING(mutex, sizeof(*mutex)); } else { mutex_is_init = 0; } Now, is this really a regression ? It might in fact be a feature :). If there is no synchronisation mechanism between a thread doing lock/unlock and another thread calling pthread_mutex_destroy, then if the thread doing lock/unlock is slow, the mutex could be destroyed while it is locked (or even before the locking thread has started to lock it. And then the locking thread might try to lock a destroyed mutex. Philippe |
|
From: Saurabh T <sa...@ho...> - 2013-11-08 19:20:39
|
---------------------------------------- > Date: Fri, 8 Nov 2013 08:20:24 +0100 > Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy > From: mag...@gm... > To: sa...@ho... > CC: val...@li... > > That is most definitely wrong. Thread 1 destroys a locked mutex, and > according to http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html > : >> Attempting to destroy a locked mutex results in undefined behavior. > > BR > Magnus Reftel You are right. But I was wrong about what was going on. The mutex *is* destroyed after unlocking. Sorry. I guess I will put in a suppression for now. saurabh |
|
From: Magnus R. <mag...@gm...> - 2013-11-08 07:20:32
|
On 7 November 2013 18:21, Saurabh T <sa...@ho...> wrote: > ---------------------------------------- >> From: fa...@kd... >> To: val...@li... >> CC: sa...@ho... >> Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy >> Date: Thu, 7 Nov 2013 17:25:57 +0100 >> >> On Thursday 07 November 2013 16:22:56 Saurabh T wrote: >>> Helgrind seems to be reporting false positive data race when >>> pthread_mutex_destroy is called in a different thread from >>> pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But >>> here's the relevant output: >>> <snip> >> >> Can you prove that the destroy cannot happen during the unlock? > > Not without code of course, but I dont believe it can. It can however happen *before* the unlock. I believe this is allowed by the standard? The code is something like this: > Thread 1: > locks > deletes > unlocks > Thread 2: > locks > does_stuff > unlocks > > saurabh > That is most definitely wrong. Thread 1 destroys a locked mutex, and according to http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html : > Attempting to destroy a locked mutex results in undefined behavior. BR Magnus Reftel |
|
From: Juan N. <one...@gm...> - 2013-11-07 18:01:56
|
Yes, the thing is I looked for that error message, and deleted the file as suggested in other forums, but after that my machine had to be rebooted and I didn't realize that this file had reappeared... too bad! I'll try to create a test case and will file a report against the corresponding tracker. Thanks for the help On Thu, Nov 7, 2013 at 6:59 PM, Dan Kegel <da...@ke...> wrote: > I found the trick by googling the error message you found after > ignoring sigpipe, "ICE default IO error handler". > There are lots of people complaining about it, and removing > .ICEAuthority was listed as a workaround. > I have no idea what the cause is. > > It might help if you could create a minimal test case and file > a bug showing how to reproduce the problem from source. > Filing against valgrind would be wrong but might be a good > enough place to start. > > On Thu, Nov 7, 2013 at 9:47 AM, Juan Navarro <one...@gm...> wrote: >> Yes, that did the trick! >> I had previously deleted that file, but restarting afterwards the PC, >> it gets recreated. If I try valgrind without the file existing, then >> the app initializes and runs. I guess this .ICEAuthority file gets >> regenerated every time the PC is rebooted; is there a way to >> permanently fix the issue? >> Actually, on the Qt side, this message appeared: >> Qt: Session management error: Authentication Rejected, reason : None >> of the authentication protocols specified are supported and host-based >> authentication failed >> >> (which makes sense since the deleted file is what controls the >> session, but I don't really know the details about it). >> Is it, maybe, a bug in the way Qt handles the user session? >> >> On Thu, Nov 7, 2013 at 4:44 PM, Dan Kegel <da...@ke...> wrote: >>> Does renaming the file ~/.ICEAuthority affect the problem? >>> >>> On Thu, Nov 7, 2013 at 7:05 AM, Juan Navarro <one...@gm...> wrote: >>>> Hello all; >>>> I'm trying to analyze my application with the newly released Valgrind >>>> v3.9.0; for the most part it works greatly, but there is some crash >>>> happening when enabling the option "track-origins". This is a desktop >>>> app compiled under GCC 4.6, which makes heavy use of Qt (4.8) + QML, >>>> FreeType, OpenGL and several multimedia libraries, among others. >>>> >>>> This is my valgrind command: >>>> $ valgrind \ >>>> --tool=memcheck \ >>>> --verbose \ >>>> --error-limit=no \ >>>> --suppressions=myapp.supp \ >>>> --log-file=valgrind-run.log \ >>>> --smc-check=all-non-file \ >>>> --leak-check=no \ >>>> --track-origins=yes \ >>>> ./myapp >>>> >>>> The reason for "smc-check" is that Qt uses JIT code for its QtScript >>>> and QML modules. "leak-check" is disables as a mean of limiting the >>>> scope of the test, and "track-origins" is what makes the command to >>>> fail (removing this option will correctly launch the app under >>>> Valgrind). >>>> >>>> This is what I get in the stdout: >>>> (myapp messages) >>>> Killed >>>> >>>> This is what I get in valgrind-run.log: >>>> (Lots of "--3538-- Reading syms from <file>") >>>> (Lots of "--3538-- REDIR: <some address> <some symbol>) >>>> ==3538== Process terminating with default action of signal 13 (SIGPIPE) >>>> ==3538== at 0x74FECCD: ??? (syscall-template.S:82) >>>> ==3538== by 0xD9B4D0E: ??? (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >>>> ==3538== by 0xD9B9BD7: _IceWrite (in >>>> /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >>>> ==3538== by 0xD9B9CC3: IceFlush (in >>>> /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >>>> ==3538== by 0x654FB60: ??? (in >>>> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >>>> ==3538== by 0x6550698: ??? (in >>>> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >>>> ==3538== by 0x6563ADA: ??? (in >>>> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >>>> ==3538== by 0x6564618: ??? (in >>>> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >>>> ==3538== by 0xD7A9DFE: _SmcProcessMessage (in >>>> /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1) >>>> ==3538== by 0xD9BDFD5: IceProcessMessages (in >>>> /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >>>> ==3538== by 0x719CD60: QMetaObject::activate(QObject*, >>>> QMetaObject const*, int, void**) (in >>>> /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) >>>> ==3538== by 0x71E91DD: QSocketNotifier::activated(int) (in >>>> /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) >>>> --3538-- Discarding syms at 0x153e95d0-0x153eafa8 in >>>> /usr/lib/x86_64-linux-gnu/gconv/UTF-16.so due to munmap() >>>> >>>> Now it is obvious that the problem comes from the Kernel emiting the >>>> SIGPIPE signal, which afaik means that someone tried to write into a >>>> pipe for which nobody is listening on the other end. I'd like to ask >>>> you about some insight on what is being done when the "track-origins" >>>> option is enabled, and if this SIGPIPE is happening due to something >>>> done in either the Valgrind side or in my app side. >>>> >>>> Now, in trying the easy and ugly approach, I just tried to omit the >>>> SIGPIPE signal, by using this call in my app's initialization: >>>> signal(SIGPIPE, SIG_IGN); >>>> >>>> The results are that nothing interesting is written into the >>>> "valgrind-run.log" file, and this is what appears in the stdout: >>>> ICE default IO error handler doing an exit(), pid = 3538, errno = 32 >>>> >>>> In either case, the signal is emitted just before any text is shown on >>>> screen: the app has a splash screen showing some letters (in order to >>>> force the preload of all font related stuff). This splash screen >>>> appears, but without any contents, before the SIGPIPE comes into >>>> action. May this have anything to do with the problem? >>>> >>>> If you read up to here: thank you very much for your time :) >>>> >>>> ------------------------------------------------------------------------------ >>>> November Webinars for C, C++, Fortran Developers >>>> Accelerate application performance with scalable programming models. Explore >>>> techniques for threading, error checking, porting, and tuning. Get the most >>>> from the latest Intel processors and coprocessors. See abstracts and register >>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Valgrind-users mailing list >>>> Val...@li... >>>> https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dan K. <da...@ke...> - 2013-11-07 17:59:42
|
I found the trick by googling the error message you found after ignoring sigpipe, "ICE default IO error handler". There are lots of people complaining about it, and removing .ICEAuthority was listed as a workaround. I have no idea what the cause is. It might help if you could create a minimal test case and file a bug showing how to reproduce the problem from source. Filing against valgrind would be wrong but might be a good enough place to start. On Thu, Nov 7, 2013 at 9:47 AM, Juan Navarro <one...@gm...> wrote: > Yes, that did the trick! > I had previously deleted that file, but restarting afterwards the PC, > it gets recreated. If I try valgrind without the file existing, then > the app initializes and runs. I guess this .ICEAuthority file gets > regenerated every time the PC is rebooted; is there a way to > permanently fix the issue? > Actually, on the Qt side, this message appeared: > Qt: Session management error: Authentication Rejected, reason : None > of the authentication protocols specified are supported and host-based > authentication failed > > (which makes sense since the deleted file is what controls the > session, but I don't really know the details about it). > Is it, maybe, a bug in the way Qt handles the user session? > > On Thu, Nov 7, 2013 at 4:44 PM, Dan Kegel <da...@ke...> wrote: >> Does renaming the file ~/.ICEAuthority affect the problem? >> >> On Thu, Nov 7, 2013 at 7:05 AM, Juan Navarro <one...@gm...> wrote: >>> Hello all; >>> I'm trying to analyze my application with the newly released Valgrind >>> v3.9.0; for the most part it works greatly, but there is some crash >>> happening when enabling the option "track-origins". This is a desktop >>> app compiled under GCC 4.6, which makes heavy use of Qt (4.8) + QML, >>> FreeType, OpenGL and several multimedia libraries, among others. >>> >>> This is my valgrind command: >>> $ valgrind \ >>> --tool=memcheck \ >>> --verbose \ >>> --error-limit=no \ >>> --suppressions=myapp.supp \ >>> --log-file=valgrind-run.log \ >>> --smc-check=all-non-file \ >>> --leak-check=no \ >>> --track-origins=yes \ >>> ./myapp >>> >>> The reason for "smc-check" is that Qt uses JIT code for its QtScript >>> and QML modules. "leak-check" is disables as a mean of limiting the >>> scope of the test, and "track-origins" is what makes the command to >>> fail (removing this option will correctly launch the app under >>> Valgrind). >>> >>> This is what I get in the stdout: >>> (myapp messages) >>> Killed >>> >>> This is what I get in valgrind-run.log: >>> (Lots of "--3538-- Reading syms from <file>") >>> (Lots of "--3538-- REDIR: <some address> <some symbol>) >>> ==3538== Process terminating with default action of signal 13 (SIGPIPE) >>> ==3538== at 0x74FECCD: ??? (syscall-template.S:82) >>> ==3538== by 0xD9B4D0E: ??? (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >>> ==3538== by 0xD9B9BD7: _IceWrite (in >>> /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >>> ==3538== by 0xD9B9CC3: IceFlush (in >>> /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >>> ==3538== by 0x654FB60: ??? (in >>> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >>> ==3538== by 0x6550698: ??? (in >>> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >>> ==3538== by 0x6563ADA: ??? (in >>> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >>> ==3538== by 0x6564618: ??? (in >>> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >>> ==3538== by 0xD7A9DFE: _SmcProcessMessage (in >>> /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1) >>> ==3538== by 0xD9BDFD5: IceProcessMessages (in >>> /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >>> ==3538== by 0x719CD60: QMetaObject::activate(QObject*, >>> QMetaObject const*, int, void**) (in >>> /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) >>> ==3538== by 0x71E91DD: QSocketNotifier::activated(int) (in >>> /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) >>> --3538-- Discarding syms at 0x153e95d0-0x153eafa8 in >>> /usr/lib/x86_64-linux-gnu/gconv/UTF-16.so due to munmap() >>> >>> Now it is obvious that the problem comes from the Kernel emiting the >>> SIGPIPE signal, which afaik means that someone tried to write into a >>> pipe for which nobody is listening on the other end. I'd like to ask >>> you about some insight on what is being done when the "track-origins" >>> option is enabled, and if this SIGPIPE is happening due to something >>> done in either the Valgrind side or in my app side. >>> >>> Now, in trying the easy and ugly approach, I just tried to omit the >>> SIGPIPE signal, by using this call in my app's initialization: >>> signal(SIGPIPE, SIG_IGN); >>> >>> The results are that nothing interesting is written into the >>> "valgrind-run.log" file, and this is what appears in the stdout: >>> ICE default IO error handler doing an exit(), pid = 3538, errno = 32 >>> >>> In either case, the signal is emitted just before any text is shown on >>> screen: the app has a splash screen showing some letters (in order to >>> force the preload of all font related stuff). This splash screen >>> appears, but without any contents, before the SIGPIPE comes into >>> action. May this have anything to do with the problem? >>> >>> If you read up to here: thank you very much for your time :) >>> >>> ------------------------------------------------------------------------------ >>> November Webinars for C, C++, Fortran Developers >>> Accelerate application performance with scalable programming models. Explore >>> techniques for threading, error checking, porting, and tuning. Get the most >>> from the latest Intel processors and coprocessors. See abstracts and register >>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Valgrind-users mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Juan N. <one...@gm...> - 2013-11-07 17:47:57
|
Yes, that did the trick! I had previously deleted that file, but restarting afterwards the PC, it gets recreated. If I try valgrind without the file existing, then the app initializes and runs. I guess this .ICEAuthority file gets regenerated every time the PC is rebooted; is there a way to permanently fix the issue? Actually, on the Qt side, this message appeared: Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed (which makes sense since the deleted file is what controls the session, but I don't really know the details about it). Is it, maybe, a bug in the way Qt handles the user session? On Thu, Nov 7, 2013 at 4:44 PM, Dan Kegel <da...@ke...> wrote: > Does renaming the file ~/.ICEAuthority affect the problem? > > On Thu, Nov 7, 2013 at 7:05 AM, Juan Navarro <one...@gm...> wrote: >> Hello all; >> I'm trying to analyze my application with the newly released Valgrind >> v3.9.0; for the most part it works greatly, but there is some crash >> happening when enabling the option "track-origins". This is a desktop >> app compiled under GCC 4.6, which makes heavy use of Qt (4.8) + QML, >> FreeType, OpenGL and several multimedia libraries, among others. >> >> This is my valgrind command: >> $ valgrind \ >> --tool=memcheck \ >> --verbose \ >> --error-limit=no \ >> --suppressions=myapp.supp \ >> --log-file=valgrind-run.log \ >> --smc-check=all-non-file \ >> --leak-check=no \ >> --track-origins=yes \ >> ./myapp >> >> The reason for "smc-check" is that Qt uses JIT code for its QtScript >> and QML modules. "leak-check" is disables as a mean of limiting the >> scope of the test, and "track-origins" is what makes the command to >> fail (removing this option will correctly launch the app under >> Valgrind). >> >> This is what I get in the stdout: >> (myapp messages) >> Killed >> >> This is what I get in valgrind-run.log: >> (Lots of "--3538-- Reading syms from <file>") >> (Lots of "--3538-- REDIR: <some address> <some symbol>) >> ==3538== Process terminating with default action of signal 13 (SIGPIPE) >> ==3538== at 0x74FECCD: ??? (syscall-template.S:82) >> ==3538== by 0xD9B4D0E: ??? (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >> ==3538== by 0xD9B9BD7: _IceWrite (in >> /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >> ==3538== by 0xD9B9CC3: IceFlush (in >> /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >> ==3538== by 0x654FB60: ??? (in >> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >> ==3538== by 0x6550698: ??? (in >> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >> ==3538== by 0x6563ADA: ??? (in >> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >> ==3538== by 0x6564618: ??? (in >> /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) >> ==3538== by 0xD7A9DFE: _SmcProcessMessage (in >> /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1) >> ==3538== by 0xD9BDFD5: IceProcessMessages (in >> /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) >> ==3538== by 0x719CD60: QMetaObject::activate(QObject*, >> QMetaObject const*, int, void**) (in >> /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) >> ==3538== by 0x71E91DD: QSocketNotifier::activated(int) (in >> /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) >> --3538-- Discarding syms at 0x153e95d0-0x153eafa8 in >> /usr/lib/x86_64-linux-gnu/gconv/UTF-16.so due to munmap() >> >> Now it is obvious that the problem comes from the Kernel emiting the >> SIGPIPE signal, which afaik means that someone tried to write into a >> pipe for which nobody is listening on the other end. I'd like to ask >> you about some insight on what is being done when the "track-origins" >> option is enabled, and if this SIGPIPE is happening due to something >> done in either the Valgrind side or in my app side. >> >> Now, in trying the easy and ugly approach, I just tried to omit the >> SIGPIPE signal, by using this call in my app's initialization: >> signal(SIGPIPE, SIG_IGN); >> >> The results are that nothing interesting is written into the >> "valgrind-run.log" file, and this is what appears in the stdout: >> ICE default IO error handler doing an exit(), pid = 3538, errno = 32 >> >> In either case, the signal is emitted just before any text is shown on >> screen: the app has a splash screen showing some letters (in order to >> force the preload of all font related stuff). This splash screen >> appears, but without any contents, before the SIGPIPE comes into >> action. May this have anything to do with the problem? >> >> If you read up to here: thank you very much for your time :) >> >> ------------------------------------------------------------------------------ >> November Webinars for C, C++, Fortran Developers >> Accelerate application performance with scalable programming models. Explore >> techniques for threading, error checking, porting, and tuning. Get the most >> from the latest Intel processors and coprocessors. See abstracts and register >> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Saurabh T <sa...@ho...> - 2013-11-07 17:21:51
|
---------------------------------------- > From: fa...@kd... > To: val...@li... > CC: sa...@ho... > Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy > Date: Thu, 7 Nov 2013 17:25:57 +0100 > > On Thursday 07 November 2013 16:22:56 Saurabh T wrote: >> Helgrind seems to be reporting false positive data race when >> pthread_mutex_destroy is called in a different thread from >> pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But >> here's the relevant output: >> <snip> > > Can you prove that the destroy cannot happen during the unlock? Not without code of course, but I dont believe it can. It can however happen *before* the unlock. I believe this is allowed by the standard? The code is something like this: Thread 1: locks deletes unlocks Thread 2: locks does_stuff unlocks saurabh > >> This was not a problem with 3.8.1 so appears to be a regression or new bug. > > ... or a fix, which detects an actual problem in the code :) > > -- > David Faure, fa...@kd..., http://www.davidfaure.fr > Working on KDE, in particular KDE Frameworks 5 > |
|
From: David F. <fa...@kd...> - 2013-11-07 16:26:10
|
On Thursday 07 November 2013 16:22:56 Saurabh T wrote: > Helgrind seems to be reporting false positive data race when > pthread_mutex_destroy is called in a different thread from > pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But > here's the relevant output: > > ==15996== Possible data race during read of size 1 at 0x4DA7F90 by thread #1 > ==15996== Locks held: none > ==15996== at 0x4A08D79: my_memcmp (hg_intercepts.c:165) > ==15996== by 0x4A0906F: pthread_mutex_destroy (hg_intercepts.c:473) > <snip> > ==15996== > ==15996== This conflicts with a previous write of size 4 by thread #52 > ==15996== Locks held: none > ==15996== at 0x34EF80D5E2: __lll_unlock_wake (in > /lib64/libpthread-2.5.so) ==15996== by 0x34EF80A0E6: _L_unlock_766 (in > /lib64/libpthread-2.5.so) ==15996== by 0x34EF80A04C: > pthread_mutex_unlock (in /lib64/libpthread-2.5.so) ==15996== by > 0x4A097E0: pthread_mutex_unlock (hg_intercepts.c:635) <snip> > ==15996== > ==15996== Address 0x4DA7F90 is 0 bytes inside a block of size 40 alloc'd > ==15996== at 0x4A08BE5: operator new(unsigned long) > (vg_replace_malloc.c:319) <snip> Can you prove that the destroy cannot happen during the unlock? > This was not a problem with 3.8.1 so appears to be a regression or new bug. ... or a fix, which detects an actual problem in the code :) -- David Faure, fa...@kd..., http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 |
|
From: Saurabh T <sa...@ho...> - 2013-11-07 16:23:03
|
Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: ==15996== Possible data race during read of size 1 at 0x4DA7F90 by thread #1 ==15996== Locks held: none ==15996== at 0x4A08D79: my_memcmp (hg_intercepts.c:165) ==15996== by 0x4A0906F: pthread_mutex_destroy (hg_intercepts.c:473) <snip> ==15996== ==15996== This conflicts with a previous write of size 4 by thread #52 ==15996== Locks held: none ==15996== at 0x34EF80D5E2: __lll_unlock_wake (in /lib64/libpthread-2.5.so) ==15996== by 0x34EF80A0E6: _L_unlock_766 (in /lib64/libpthread-2.5.so) ==15996== by 0x34EF80A04C: pthread_mutex_unlock (in /lib64/libpthread-2.5.so) ==15996== by 0x4A097E0: pthread_mutex_unlock (hg_intercepts.c:635) <snip> ==15996== ==15996== Address 0x4DA7F90 is 0 bytes inside a block of size 40 alloc'd ==15996== at 0x4A08BE5: operator new(unsigned long) (vg_replace_malloc.c:319) <snip> This was not a problem with 3.8.1 so appears to be a regression or new bug. saurabh |
|
From: Dan K. <da...@ke...> - 2013-11-07 15:44:27
|
Does renaming the file ~/.ICEAuthority affect the problem? On Thu, Nov 7, 2013 at 7:05 AM, Juan Navarro <one...@gm...> wrote: > Hello all; > I'm trying to analyze my application with the newly released Valgrind > v3.9.0; for the most part it works greatly, but there is some crash > happening when enabling the option "track-origins". This is a desktop > app compiled under GCC 4.6, which makes heavy use of Qt (4.8) + QML, > FreeType, OpenGL and several multimedia libraries, among others. > > This is my valgrind command: > $ valgrind \ > --tool=memcheck \ > --verbose \ > --error-limit=no \ > --suppressions=myapp.supp \ > --log-file=valgrind-run.log \ > --smc-check=all-non-file \ > --leak-check=no \ > --track-origins=yes \ > ./myapp > > The reason for "smc-check" is that Qt uses JIT code for its QtScript > and QML modules. "leak-check" is disables as a mean of limiting the > scope of the test, and "track-origins" is what makes the command to > fail (removing this option will correctly launch the app under > Valgrind). > > This is what I get in the stdout: > (myapp messages) > Killed > > This is what I get in valgrind-run.log: > (Lots of "--3538-- Reading syms from <file>") > (Lots of "--3538-- REDIR: <some address> <some symbol>) > ==3538== Process terminating with default action of signal 13 (SIGPIPE) > ==3538== at 0x74FECCD: ??? (syscall-template.S:82) > ==3538== by 0xD9B4D0E: ??? (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) > ==3538== by 0xD9B9BD7: _IceWrite (in > /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) > ==3538== by 0xD9B9CC3: IceFlush (in > /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) > ==3538== by 0x654FB60: ??? (in > /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) > ==3538== by 0x6550698: ??? (in > /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) > ==3538== by 0x6563ADA: ??? (in > /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) > ==3538== by 0x6564618: ??? (in > /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) > ==3538== by 0xD7A9DFE: _SmcProcessMessage (in > /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1) > ==3538== by 0xD9BDFD5: IceProcessMessages (in > /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) > ==3538== by 0x719CD60: QMetaObject::activate(QObject*, > QMetaObject const*, int, void**) (in > /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) > ==3538== by 0x71E91DD: QSocketNotifier::activated(int) (in > /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) > --3538-- Discarding syms at 0x153e95d0-0x153eafa8 in > /usr/lib/x86_64-linux-gnu/gconv/UTF-16.so due to munmap() > > Now it is obvious that the problem comes from the Kernel emiting the > SIGPIPE signal, which afaik means that someone tried to write into a > pipe for which nobody is listening on the other end. I'd like to ask > you about some insight on what is being done when the "track-origins" > option is enabled, and if this SIGPIPE is happening due to something > done in either the Valgrind side or in my app side. > > Now, in trying the easy and ugly approach, I just tried to omit the > SIGPIPE signal, by using this call in my app's initialization: > signal(SIGPIPE, SIG_IGN); > > The results are that nothing interesting is written into the > "valgrind-run.log" file, and this is what appears in the stdout: > ICE default IO error handler doing an exit(), pid = 3538, errno = 32 > > In either case, the signal is emitted just before any text is shown on > screen: the app has a splash screen showing some letters (in order to > force the preload of all font related stuff). This splash screen > appears, but without any contents, before the SIGPIPE comes into > action. May this have anything to do with the problem? > > If you read up to here: thank you very much for your time :) > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Juan N. <one...@gm...> - 2013-11-07 15:05:48
|
Hello all;
I'm trying to analyze my application with the newly released Valgrind
v3.9.0; for the most part it works greatly, but there is some crash
happening when enabling the option "track-origins". This is a desktop
app compiled under GCC 4.6, which makes heavy use of Qt (4.8) + QML,
FreeType, OpenGL and several multimedia libraries, among others.
This is my valgrind command:
$ valgrind \
--tool=memcheck \
--verbose \
--error-limit=no \
--suppressions=myapp.supp \
--log-file=valgrind-run.log \
--smc-check=all-non-file \
--leak-check=no \
--track-origins=yes \
./myapp
The reason for "smc-check" is that Qt uses JIT code for its QtScript
and QML modules. "leak-check" is disables as a mean of limiting the
scope of the test, and "track-origins" is what makes the command to
fail (removing this option will correctly launch the app under
Valgrind).
This is what I get in the stdout:
(myapp messages)
Killed
This is what I get in valgrind-run.log:
(Lots of "--3538-- Reading syms from <file>")
(Lots of "--3538-- REDIR: <some address> <some symbol>)
==3538== Process terminating with default action of signal 13 (SIGPIPE)
==3538== at 0x74FECCD: ??? (syscall-template.S:82)
==3538== by 0xD9B4D0E: ??? (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0)
==3538== by 0xD9B9BD7: _IceWrite (in
/usr/lib/x86_64-linux-gnu/libICE.so.6.3.0)
==3538== by 0xD9B9CC3: IceFlush (in
/usr/lib/x86_64-linux-gnu/libICE.so.6.3.0)
==3538== by 0x654FB60: ??? (in
/opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4)
==3538== by 0x6550698: ??? (in
/opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4)
==3538== by 0x6563ADA: ??? (in
/opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4)
==3538== by 0x6564618: ??? (in
/opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4)
==3538== by 0xD7A9DFE: _SmcProcessMessage (in
/usr/lib/x86_64-linux-gnu/libSM.so.6.0.1)
==3538== by 0xD9BDFD5: IceProcessMessages (in
/usr/lib/x86_64-linux-gnu/libICE.so.6.3.0)
==3538== by 0x719CD60: QMetaObject::activate(QObject*,
QMetaObject const*, int, void**) (in
/opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4)
==3538== by 0x71E91DD: QSocketNotifier::activated(int) (in
/opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4)
--3538-- Discarding syms at 0x153e95d0-0x153eafa8 in
/usr/lib/x86_64-linux-gnu/gconv/UTF-16.so due to munmap()
Now it is obvious that the problem comes from the Kernel emiting the
SIGPIPE signal, which afaik means that someone tried to write into a
pipe for which nobody is listening on the other end. I'd like to ask
you about some insight on what is being done when the "track-origins"
option is enabled, and if this SIGPIPE is happening due to something
done in either the Valgrind side or in my app side.
Now, in trying the easy and ugly approach, I just tried to omit the
SIGPIPE signal, by using this call in my app's initialization:
signal(SIGPIPE, SIG_IGN);
The results are that nothing interesting is written into the
"valgrind-run.log" file, and this is what appears in the stdout:
ICE default IO error handler doing an exit(), pid = 3538, errno = 32
In either case, the signal is emitted just before any text is shown on
screen: the app has a splash screen showing some letters (in order to
force the preload of all font related stuff). This splash screen
appears, but without any contents, before the SIGPIPE comes into
action. May this have anything to do with the problem?
If you read up to here: thank you very much for your time :)
|
|
From: John R. <jr...@Bi...> - 2013-11-07 01:52:29
|
> I am trying to run valgrind on a target which is ppc32 and it has wind
> river linux.
> I am successful in getting the valgrind related files and when I run
> valgrind, I am getting the following issue.
> Could somebody help me.
The message really is very clear! Do what it says after "Possible fixes".
If you don't understand what it says, then find someone else who does,
and ask them to help you. Someone who is familiar with shared libraries
and execve() on Linux probably will understand.
If you still have problems, then file a bug report against valgrind.
See the "Bug reports" link in the left column of the main web page.
Please include the name of your Linux distribution, its version number,
the version number of the Linux kernel (copy+paste the output from "uname -a"),
and the version number of the libc shared library. For example,
on x86_64 systems the file /lib*/libc.so.6 is a symlink to another file
such as "libc-2.17.so" which means that the version of libc is 2.17.
To make the bug report even more useful, then please run
readelf --headers /bin/date
and look for "INTERP", such as:
-----
INTERP 0x0000000000000238 0x0000000000400238 0x0000000000400238
0x000000000000001c 0x000000000000001c R 1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
-----
Then run
readelf --symbols /lib64/ld-linux-x86-64.so.2 | grep str
but use the filename that you see in *YOUR* output on the second line
after "INTERP". Then copy+paste the output of all the lines containing "str"
into the bug report.
>
>
> root@lc1:/lc/isan/valgrind-3.8.1/bin# valgrind
> /isan/bin/port_client(image on the target)
> ==3536== Memcheck, a memory error detector
> ==3536== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==3536== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==3536== Command: /isan/bin/port_client
> ==3536==
>
> 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: strlen
> valgrind: in an object with soname matching: ld.so.1
> valgrind: was not found whilst processing
> valgrind: symbols from the object with soname: ld.so.1
> valgrind:
> valgrind: Possible fixes: (1, short term): install glibc's debuginfo
> valgrind: package on this machine. (2, longer term): ask the packagers
> valgrind: for your Linux distribution to please in future ship a non-
> valgrind: stripped ld.so (or whatever the dynamic linker .so is called)
> valgrind: that exports the above-named function using the standard
> valgrind: calling conventions for this platform. The package you need
> valgrind: to install for fix (1) is called
> valgrind:
> valgrind: On Debian, Ubuntu: libc6-dbg
> valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo
> valgrind:
> valgrind: Cannot continue -- exiting now. Sorry.
|
|
From: David L. <dav...@sb...> - 2013-11-06 20:39:02
|
Your error occurs if the Wind River project was configured either with '--enable-build=production' or else without any '--enable-build'' configure option since the default build type is 'production'. To fix this for both Wind River Linux versions 4 and 5, reconfigure your platform project with the 'debug' build option: configure --enable-build=debug ... (your other configure options) Then rebuild the filesystem: make fs Hope this helps, Dave |
|
From: Bhaskararao V. (bvakamul) <bva...@ci...> - 2013-11-06 18:21:00
|
Hi All,
I am trying to run valgrind on a target which is ppc32 and it has wind
river linux.
I am successful in getting the valgrind related files and when I run
valgrind, I am getting the following issue.
Could somebody help me.
root@lc1:/lc/isan/valgrind-3.8.1/bin# valgrind
/isan/bin/port_client(image on the target)
==3536== Memcheck, a memory error detector
==3536== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==3536== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==3536== Command: /isan/bin/port_client
==3536==
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: strlen
valgrind: in an object with soname matching: ld.so.1
valgrind: was not found whilst processing
valgrind: symbols from the object with soname: ld.so.1
valgrind:
valgrind: Possible fixes: (1, short term): install glibc's debuginfo
valgrind: package on this machine. (2, longer term): ask the packagers
valgrind: for your Linux distribution to please in future ship a non-
valgrind: stripped ld.so (or whatever the dynamic linker .so is called)
valgrind: that exports the above-named function using the standard
valgrind: calling conventions for this platform. The package you need
valgrind: to install for fix (1) is called
valgrind:
valgrind: On Debian, Ubuntu: libc6-dbg
valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo
valgrind:
valgrind: Cannot continue -- exiting now. Sorry.
Thanks and Regards,
Bhaskararao V
Work : +1 408 525 7147
Cell : +1 510 598 5928
On 11/3/13 6:06 AM, "John Reiser" <jr...@Bi...> wrote:
>> I have built something that does this now - it turned out to be
>>relatively simple
>> - it's a bit of a hacked up mess at the moment, but if anybody is
>>interested feel free to contact me on or off the list.
>
>It is appropriate to publish patches that compile and work.
>Then the debate will be "How worthwhile is this concrete change?"
>instead of "There is a rumor that ...". Please post your patch.
>
>
>--------------------------------------------------------------------------
>----
>Android is increasing in popularity, but the open development platform
>that
>developers love is also attractive to malware creators. Download this
>white
>paper to learn more about secure code signing practices that can help keep
>Android apps secure.
>http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktr
>k
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: John R. <jr...@Bi...> - 2013-11-03 15:05:12
|
> I have built something that does this now - it turned out to be relatively simple > - it's a bit of a hacked up mess at the moment, but if anybody is interested feel free to contact me on or off the list. It is appropriate to publish patches that compile and work. Then the debate will be "How worthwhile is this concrete change?" instead of "There is a rumor that ...". Please post your patch. |
|
From: Adrian M. <ac...@yo...> - 2013-11-03 14:39:58
|
On 1 November 2013 16:18, Adrian Mcmenamin <ac...@yo...> wrote: > Dear all, > > I would like to add thread ID to lackey memory tracing output. > > > I have built something that does this now - it turned out to be relatively simple - it's a bit of a hacked up mess at the moment, but if anybody is interested feel free to contact me on or off the list. Adrian |
|
From: John R. <jr...@Bi...> - 2013-11-02 22:09:53
|
> I want to observe the binary translation and instrumentation progress, which translate machine code to tree IR first, then translate tree IR to flat IR and do instrumentation, finally rebuild tree IR and output machine code, just like section 3.7 of "Valgrind: A Framework for Heavyweight Dynamic
> Binary Instrumentation". I have try --help-debug but I cannot find any relevant option. Is it possible to dump these information by any option?
Errr, did you read the output? "valgrind --help-debug /bin/date"
[[snip]]
Vex options for all Valgrind tools:
--vex-iropt-verbosity=<0..9> [0]
--vex-iropt-level=<0..2> [2]
--vex-iropt-register-updates=unwindregs-at-mem-access
|allregs-at-mem-access
|allregs-at-each-insn [unwindregs-at-mem-access]
--vex-iropt-unroll-thresh=<0..400> [120]
--vex-guest-max-insns=<1..100> [50]
--vex-guest-chase-thresh=<0..99> [10]
--vex-guest-chase-cond=no|yes [no]
--trace-flags and --profile-flags values (omit the middle space):
1000 0000 show conversion into IR <<<<< RIGHT HERE (etc.)
0100 0000 show after initial opt
0010 0000 show after instrumentation
0001 0000 show after second opt
0000 1000 show after tree building
0000 0100 show selecting insns
0000 0010 show after reg-alloc
0000 0001 show final assembly
(Nb: you need --trace-notbelow and/or --trace-notabove with --trace-flags for full details)
debugging options for Valgrind tools that report errors
--dump-error=<number> show translation for basic block associated
with <number>'th error context [0=show none]
[[snip]]
|
188 messages has been excluded from this view by a project administrator.
