valgrind-users — General discussion list for Valgrind users

[Valgrind-users] How to dump the VEX IR and generated assembly during translation

[Lu M. <kin...@gm...>]

Hello all,

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?

Thanks a lot

Re: [Valgrind-users] Running massif on code with custom allocator with non-malloc-like API

[Konstantin T. <an...@ya...>]

31.10.2013, 19:38, "Philippe Waroquiers" <phi...@sk...>:
> On Thu, 2013-10-31 at 14:06 +0400, Konstantin Tokarev wrote:
>
>>  Hi all,
>>
>>  I'm trying to use massif to analyze memory usage of WebKit. I build it without embedded tcmalloc, so
>>  "normal" heap allocations are traced by massif. However, its JavaScript engine still uses separate
>>  mmap-based heap. How can I trace allocations made in this heap with massif? API is not malloc-like,
>>  so I guess I need to write some code to get this functions replaced in Valgrind.
>>
>>  P.S. I've tried --pages-as-heap=yes to trace mmap directly, but results were completely garbage.
>
> massif supports the client requests VALGRIND_MALLOCLIKE_BLOCK,
> VALGRIND_RESIZEINPLACE_BLOCK and  VALGRIND_FREELIKE_BLOCK.
> Inserting calls to these inside the JavaScript engine where it
> allocates, re-allocates and frees blocks should allow to describe
> memory usage by the JavaScript engine.

Thank you!

-- 
Regards,
Konstantin

[Valgrind-users] Is support for Mac Os X 10.9 planned?

[Guido P. <coc...@gm...>]

Dear developers,

First of all, thank you for sharing with us this wonderful piece of
software! It saved my researcher's ass several times already :-)

I was wondering whether you plan to support Mac Os X 10.9 (aka Maverick) in
the near future.

Cheers,
Guido

[Valgrind-users] Adding thread ID to lackey output in Linux (amd64)

[Adrian M. <ac...@yo...>]

Dear all,

I would like to add thread ID to lackey memory tracing output.

I can see where the calls are made in lk_instrument, but was hoping someone
could give me a shortcut to going through all the headers etc by pointing
me to the easiest way to capture the thread id (not the process ID) so I
can add this to the calls.


As an aside - I will also be changing the output to XML so I can apply
library tools directly - presently I use a Groovy script to convert lackey
output to XML and run analysis on that - but could probably save myself a
day or two of wall clock time if I did this directly!

I used lackey for my MSc -
http://cartesianproduct.wordpress.com/2011/12/17/working-set-heuristics-and-the-linux-kernel-my-msc-report/-
and there are some groovy scripts I used here -
http://github.com/mcmenaminadrian - and a DTD I wrote for lackey output -

<!DOCTYPE lackeyml [
<!ELEMENT lackeyml(application,(instruction|store|load|modify)*)>
<!ATTLIST lackeyml version CDATA #FIXED 0.1>
<!ATTLIST lackeyml xmlns CDATA #FIXED "http://cartesianproduct.wordpress.com">
<!ELEMENT application EMPTY>
<!ATTLIST application command CDATA #REQUIRED>
<!ELEMENT instruction EMPTY>
<!ATTLIST instruction address CDATA #REQUIRED>
<!ATTLIST instruction size CDATA #REQUIRED>
<!ELEMENT modify EMPTY>
<!ATTLIST modify address CDATA #REQUIRED>
<!ATTLIST modify size CDATA #REQUIRED>
<!ELEMENT store EMPTY>
<!ATTLIST store address CDATA #REQUIRED>
<!ATTLIST store size CDATA #REQUIRED>
<!ELEMENT load EMPTY>
<!ATTLIST load address CDATA #REQUIRED>
<!ATTLIST load size CDATA #REQUIRED>
]>

Many thanks

Adrian

[Valgrind-users] Unable to build on OS X

[Mark N. <mar...@me...>]

Hi Valgrind users,

I am coming across the following error when I run make:

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 armv7-unknown-linux-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether ln -s works... yes
checking for armv7-unknown-linux-gcc...
/Users/itadakimasu/Library/Developer/SDKs/android-ndk-r8e/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-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
/Users/itadakimasu/Library/Developer/SDKs/android-ndk-r8e/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc
accepts -g... yes
checking for
/Users/itadakimasu/Library/Developer/SDKs/android-ndk-r8e/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc
option to accept ISO C89... unsupported
checking for style of include used by make... GNU
checking dependency style of
/Users/itadakimasu/Library/Developer/SDKs/android-ndk-r8e/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc...
gcc3
checking whether
/Users/itadakimasu/Library/Developer/SDKs/android-ndk-r8e/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc
and cc understand -c and -o together... yes
checking how to run the C preprocessor... /lib/cpp
configure: error: in
`/Users/itadakimasu/Library/Developer/Tools/valgrind-3.9.0':
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details
make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.


Here's my build commands:

export NDKROOT=$NDK_ROOT

export HWKIND=generic


cd ./valgrind-3.9.0


# Set up toolchain paths.

#

# For ARM

export AR=$NDKROOT/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_
64/bin/arm-linux-androideabi-ar

export LD=$NDKROOT/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_
64/bin/arm-linux-androideabi-ld

export CC=$NDKROOT/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_
64/bin/arm-linux-androideabi-gcc


# for ARM

CPPFLAGS="--sysroot=$NDKROOT/platforms/android-14/arch-arm/usr
-DANDROID_HARDWARE_$HWKIND" \

   CFLAGS="--sysroot=$NDKROOT/platforms/android-14/arch-arm/usr" \

   ./configure --prefix=/data/local/Inst \

   --host=armv7-unknown-linux --target=armv7-unknown-linux \

   --with-tmpdir=/sdcard


# Build, and park the install tree in `pwd`/Inst

#

make -j2

make -j2 install DESTDIR=`pwd`/Inst


Thanks in advance,

Mark

Re: [Valgrind-users] Valgrind on Android Jelly Beans -- Can not launch app due to unrecognized instructions.

[Jun Y. <YJ...@gm...>]

Thanks John. I was using 3.8. I will give 3.9 a try. 

John Reiser <jreiser <at> BitWagon.com> writes:

> 
> >> ================from the logcat =================================
> >> I/val.sh  ( 1259): disInstr(thumb): unhandled instruction: 0xEEBA 0x7BEF
> 
> >    0x1 <abc+1>:	vcvt.f64.s32	d7, d7, #1
> 
> Also note this bug which is fixed in valgrind-3.9.0:
> 308717  ARM: implement fixed-point VCVT.F64.[SU]32

Re: [Valgrind-users] Valgrind on Android Jelly Beans -- Can not launch app due to unrecognized instructions.

[John R. <jr...@Bi...>]

>> ================from the logcat =================================
>> I/val.sh  ( 1259): disInstr(thumb): unhandled instruction: 0xEEBA 0x7BEF

>    0x1 <abc+1>:	vcvt.f64.s32	d7, d7, #1

Also note this bug which is fixed in valgrind-3.9.0:
308717  ARM: implement fixed-point VCVT.F64.[SU]32

[Valgrind-users] Valgrind-3.9.0 is available

[Julian S. <js...@ac...>]

We are pleased to announce a new release of Valgrind, version 3.9.0,
available from http://www.valgrind.org.

3.9.0 is a feature release with many improvements and the usual
collection of bug fixes.  This release adds support for MIPS64/Linux,
Intel AVX2 instructions and POWER8 instructions.  DFP support has been
added for S390.  Initial support for hardware transactional memory has
been added for Intel and POWER platforms.  Support for Mac OS X 10.8
(Mountain Lion) has been improved.  Accuracy of Memcheck on vectorized
code has been improved.

The release notes below give more details.

Our thanks to all those who contribute to Valgrind's development.
This release represents a great deal of time, energy and effort on the
part of many people.

Happy and productive debugging and profiling,

-- The Valgrind Developers


Release 3.9.0 (31 October 2013)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.9.0 is a feature release with many improvements and the usual
collection of bug fixes.

This release supports X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux,
PPC64/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android,
X86/Android, X86/MacOSX 10.7 and AMD64/MacOSX 10.7.  Support for
MacOSX 10.8 is significantly improved relative to the 3.8.0 release.

* ================== PLATFORM CHANGES =================

* Support for MIPS64 LE and BE running Linux.  Valgrind has been
  tested on MIPS64 Debian Squeeze and Debian Wheezy distributions.

* Support for MIPS DSP ASE on MIPS32 platforms.

* Support for s390x Decimal Floating Point instructions on hosts that
  have the DFP facility installed.

* Support for POWER8 (Power ISA 2.07) instructions

* Support for Intel AVX2 instructions.  This is available only on 64
  bit code.

* Initial support for Intel Transactional Synchronization Extensions,
  both RTM and HLE.

* Initial support for Hardware Transactional Memory on POWER.

* Improved support for MacOSX 10.8 (64-bit only).  Memcheck can now
  run large GUI apps tolerably well.

* ==================== TOOL CHANGES ====================

* Memcheck:

  - Improvements in handling of vectorised code, leading to
    significantly fewer false error reports.  You need to use the flag
    --partial-loads-ok=yes to get the benefits of these changes.

  - Better control over the leak checker.  It is now possible to
    specify which leak kinds (definite/indirect/possible/reachable)
    should be displayed, which should be regarded as errors, and which
    should be suppressed by a given leak suppression.  This is done
    using the options --show-leak-kinds=kind1,kind2,..,
    --errors-for-leak-kinds=kind1,kind2,.. and an optional
    "match-leak-kinds:" line in suppression entries, respectively.

    Note that generated leak suppressions contain this new line and
    are therefore more specific than in previous releases.  To get the
    same behaviour as previous releases, remove the "match-leak-kinds:"
    line from generated suppressions before using them.

  - Reduced "possible leak" reports from the leak checker by the use
    of better heuristics.  The available heuristics provide detection
    of valid interior pointers to std::stdstring, to new[] allocated
    arrays with elements having destructors and to interior pointers
    pointing to an inner part of a C++ object using multiple
    inheritance.  They can be selected individually using the
    option --leak-check-heuristics=heur1,heur2,...

  - Better control of stacktrace acquisition for heap-allocated
    blocks.  Using the --keep-stacktraces option, it is possible to
    control independently whether a stack trace is acquired for each
    allocation and deallocation.  This can be used to create better
    "use after free" errors or to decrease Valgrind's resource
    consumption by recording less information.

  - Better reporting of leak suppression usage.  The list of used
    suppressions (shown when the -v option is given) now shows, for
    each leak suppressions, how many blocks and bytes it suppressed
    during the last leak search.

* Helgrind:

  - False errors resulting from the use of statically initialised
    mutexes and condition variables (PTHREAD_MUTEX_INITIALISER, etc)
    have been removed.

  - False errors resulting from the use of pthread_cond_waits that
    timeout, have been removed.

* ==================== OTHER CHANGES ====================

* Some attempt to tune Valgrind's space requirements to the expected
  capabilities of the target:

  - The default size of the translation cache has been reduced from 8
    sectors to 6 on Android platforms, since each sector occupies
    about 40MB when using Memcheck.

  - The default size of the translation cache has been increased to 16
    sectors on all other platforms, reflecting the fact that large
    applications require instrumentation and storage of huge amounts
    of code.  For similar reasons, the number of memory mapped
    segments that can be tracked has been increased by a factor of 6.

  - In all cases, the maximum number of sectors in the translation
    cache can be controlled by the new flag --num-transtab-sectors.

* Changes in how debug info (line numbers, etc) is read:

  - Valgrind no longer temporarily mmaps the entire object to read
    from it.  Instead, reading is done through a small fixed sized
    buffer.  This avoids virtual memory usage spikes when Valgrind
    reads debuginfo from large shared objects.

  - A new experimental remote debug info server.  Valgrind can read
    debug info from a different machine (typically, a build host)
    where debuginfo objects are stored.  This can save a lot of time
    and hassle when running Valgrind on resource-constrained targets
    (phones, tablets) when the full debuginfo objects are stored
    somewhere else.  This is enabled by the --debuginfo-server=
    option.

  - Consistency checking between main and debug objects can be
    disabled using the --allow-mismatched-debuginfo option.

* Stack unwinding by stack scanning, on ARM.  Unwinding by stack
  scanning can recover stack traces in some cases when the normal
  unwind mechanisms fail.  Stack scanning is best described as "a
  nasty, dangerous and misleading hack" and so is disabled by default.
  Use --unw-stack-scan-thresh and --unw-stack-scan-frames to enable
  and control it.

* Detection and merging of recursive stack frame cycles.  When your
  program has recursive algorithms, this limits the memory used by
  Valgrind for recorded stack traces and avoids recording
  uninteresting repeated calls.  This is controlled by the command
  line option --merge-recursive-frame and by the monitor command
  "v.set merge-recursive-frames".

* File name and line numbers for used suppressions.  The list of used
  suppressions (shown when the -v option is given) now shows, for each
  used suppression, the file name and line number where the suppression
  is defined.

* New and modified GDB server monitor features:

  - valgrind.h has a new client request, VALGRIND_MONITOR_COMMAND,
    that can be used to execute gdbserver monitor commands from the
    client program.

  - A new monitor command, "v.info open_fds", that gives the list of
    open file descriptors and additional details.

  - An optional message in the "v.info n_errs_found" monitor command,
    for example "v.info n_errs_found test 1234 finished", allowing a
    comment string to be added to the process output, perhaps for the
    purpose of separating errors of different tests or test phases.

  - A new monitor command "v.info execontext" that shows information
    about the stack traces recorded by Valgrind.

  - A new monitor command "v.do expensive_sanity_check_general" to run
    some internal consistency checks.

* New flag --sigill-diagnostics to control whether a diagnostic
  message is printed when the JIT encounters an instruction it can't
  translate.  The actual behavior -- delivery of SIGILL to the
  application -- is unchanged.

* The maximum amount of memory that Valgrind can use on 64 bit targets
  has been increased from 32GB to 64GB.  This should make it possible
  to run applications on Memcheck that natively require up to about 35GB.

* ==================== FIXED BUGS ====================

The following bugs have been fixed or resolved.  Note that "n-i-bz"
stands for "not in bugzilla" -- that is, a bug that was reported to us
but never got a bugzilla entry.  We encourage you to file bugs in
bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
than mailing the developers (or mailing lists) directly -- bugs that
are not entered into bugzilla tend to get forgotten about or ignored.

To see details of a given bug, visit
  https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed below.

123837  system call: 4th argument is optional, depending on cmd
135425  memcheck should tell you where Freed blocks were Mallocd
164485  VG_N_SEGNAMES and VG_N_SEGMENTS are (still) too small
207815  Adds some of the drm ioctls to syswrap-linux.c
251569  vex amd64->IR: 0xF 0x1 0xF9 0xBF 0x90 0xD0 0x3 0x0 (RDTSCP)
252955  Impossible to compile with ccache
253519  Memcheck reports auxv pointer accesses as invalid reads.
263034  Crash when loading some PPC64 binaries
269599  Increase deepest backtrace
274695  s390x: Support "compare to/from logical" instructions (z196)
275800  s390x: Autodetect cache info (part 2)
280271  Valgrind reports possible memory leaks on still-reachable std::string
284540  Memcheck shouldn't count suppressions matching still-reachable [..]
289578  Backtraces with ARM unwind tables (stack scan flags)
296311  Wrong stack traces due to -fomit-frame-pointer (x86)
304832  ppc32: build failure
305431  Use find_buildid shdr fallback for separate .debug files
305728  Add support for AVX2 instructions
305948  ppc64: code generation for ShlD64 / ShrD64 asserts
306035  s390x: Fix IR generation for LAAG and friends
306054  s390x: Condition code computation for convert-to-int/logical
306098  s390x: alternate opcode form for convert to/from fixed
306587  Fix cache line detection from auxiliary vector for PPC.
306783  Mips unhandled syscall :  4025  /  4079  / 4182
307038  DWARF2 CFI reader: unhandled DW_OP_ opcode 0x8 (DW_OP_const1u et al)
307082  HG false positive: pthread_cond_destroy: destruction of unknown CV
307101  sys_capget second argument can be NULL
307103  sys_openat: If pathname is absolute, then dirfd is ignored.
307106  amd64->IR: f0 0f c0 02 (lock xadd byte)
307113  s390x: DFP support
307141  valgrind does't work in mips-linux system
307155  filter_gdb should filter out syscall-template.S T_PSEUDO
307285  x86_amd64 feature test for avx in test suite is wrong
307290  memcheck overlap testcase needs memcpy version filter
307463  Please add "&limit=0" to the "all open bugs" link
307465  --show-possibly-lost=no should reduce the error count / exit code
307557  Leaks on Mac OS X 10.7.5 libraries at ImageLoader::recursiveInit[..]
307729  pkgconfig support broken valgrind.pc
307828  Memcheck false errors SSE optimized wcscpy, wcscmp, wcsrchr, wcschr
307955  Building valgrind 3.7.0-r4 fails in Gentoo AMD64 when using clang
308089  Unhandled syscall on ppc64: prctl
308135  PPC32 MPC8xx has 16 bytes cache size
308321  testsuite memcheck filter interferes with gdb_filter
308333 == 307106
308341  vgdb should report process exit (or fatal signal)
308427  s390 memcheck reports tsearch cjump/cmove depends on uninit
308495  Remove build dependency on installed Xen headers
308573  Internal error on 64-bit instruction executed in 32-bit mode
308626  == 308627
308627  pmovmskb validity bit propagation is imprecise
308644  vgdb command for having the info for the track-fds option
308711  give more info about aspacemgr and arenas in out_of_memory
308717  ARM: implement fixed-point VCVT.F64.[SU]32
308718  ARM implement SMLALBB family of instructions
308886  Missing support for PTRACE_SET/GETREGSET
308930  syscall name_to_handle_at (303 on amd64) not handled
309229  V-bit tester does not report number of tests generated
309323  print unrecognized instuction on MIPS
309425  Provide a --sigill-diagnostics flag to suppress illegal [..]
309427  SSE optimized stpncpy trigger uninitialised value [..] errors
309430  Self hosting ppc64 encounters a vassert error on operand type
309600  valgrind is a bit confused about 0-sized sections
309823  Generate errors for still reachable blocks
309921  PCMPISTRI validity bit propagation is imprecise
309922  none/tests/ppc64/test_dfp5 sometimes fails
310169  The Iop_CmpORD class of Iops is not supported by the vbit checker.
310424  --read-var-info does not properly describe static variables
310792  search additional path for debug symbols
310931  s390x: Message-security assist (MSA) instruction extension [..]
311100  PPC DFP implementation of the integer operands is inconsistent [..]
311318  ARM: "128-bit constant is not implemented" error message
311407  ssse3 bcopy (actually converted memcpy) causes invalid read [..]
311690  V crashes because it redirects branches inside of a redirected function
311880  x86_64: make regtest hangs at shell_valid1
311922  WARNING: unhandled syscall: 170
311933  == 251569
312171  ppc: insn selection for DFP
312571  Rounding mode call wrong for the DFP Iops [..]
312620  Change to Iop_D32toD64 [..] for s390 DFP support broke ppc [..]
312913  Dangling pointers error should also report the alloc stack trace
312980  Building on Mountain Lion generates some compiler warnings
313267  Adding MIPS64/Linux port to Valgrind
313348  == 251569
313354  == 251569
313811  Buffer overflow in assert_fail
314099  coverity pointed out error in VEX guest_ppc_toIR.c insn_suffix
314269  ppc: dead code in insn selection
314718  ARM: implement integer divide instruction (sdiv and udiv)
315345  cl-format.xml and callgrind/dump.c don't agree on using cfl= or cfi=
315441  sendmsg syscall should ignore unset msghdr msg_flags
315534  msgrcv inside a thread causes valgrind to hang (block)
315545  Assertion '(UChar*)sec->tt[tteNo].tcptr <= (UChar*)hcode' failed
315689  disInstr(thumb): unhandled instruction: 0xF852 0x0E10 (LDRT)
315738  disInstr(arm): unhandled instruction: 0xEEBE0BEE (vcvt.s32.f64)
315959  valgrind man page has bogus SGCHECK (and no BBV) OPTIONS section
316144  valgrind.1 manpage contains unknown ??? strings [..]
316145  callgrind command line options in manpage reference (unknown) [..]
316145  callgrind command line options in manpage reference [..]
316181  drd: Fixed a 4x slowdown for certain applications
316503  Valgrind does not support SSE4 "movntdqa" instruction
316535  Use of |signed int| instead of |size_t| in valgrind messages
316696   fluidanimate program of parsec 2.1 stuck
316761  syscall open_by_handle_at (304 on amd64, 342 on x86) not handled
317091  Use -Wl,-Ttext-segment when static linking if possible [..]
317186  "Impossible happens" when occurs VCVT instruction on ARM
317318  Support for Threading Building Blocks "scalable_malloc"
317444  amd64->IR: 0xC4 0x41 0x2C 0xC2 0xD2 0x8 (vcmpeq_uqps)
317461  Fix BMI assembler configure check and avx2/bmi/fma vgtest prereqs
317463  bmi testcase IR SANITY CHECK FAILURE
317506  memcheck/tests/vbit-test fails with unknown opcode after [..]
318050  libmpiwrap fails to compile with out-of-source build
318203  setsockopt handling needs to handle SOL_SOCKET/SO_ATTACH_FILTER
318643  annotate_trace_memory tests infinite loop on arm and ppc [..]
318773  amd64->IR: 0xF3 0x48 0x0F 0xBC 0xC2 0xC3 0x66 0x0F
318929  Crash with: disInstr(thumb): 0xF321 0x0001 (ssat16)
318932  Add missing PPC64 and PPC32 system call support
319235  --db-attach=yes is broken with Yama (ptrace scoping) enabled
319395  Crash with unhandled instruction on STRT (Thumb) instructions
319494  VEX Makefile-gcc standalone build update after r2702
319505  [MIPSEL] Crash: unhandled UNRAY operator.
319858  disInstr(thumb): unhandled instruction on instruction STRBT
319932  disInstr(thumb): unhandled instruction on instruction STRHT
320057  Problems when we try to mmap more than 12 memory pages on MIPS32
320063  Memory from PTRACE_GET_THREAD_AREA is reported uninitialised
320083  disInstr(thumb): unhandled instruction on instruction LDRBT
320116  bind on AF_BLUETOOTH produces warnings because of sockaddr_rc padding
320131  WARNING: unhandled syscall: 369 on ARM (prlimit64)
320211  Stack buffer overflow in ./coregrind/m_main.c with huge TMPDIR
320661  vgModuleLocal_read_elf_debug_info(): "Assertion '!di->soname'
320895  add fanotify support (patch included)
320998  vex amd64->IR pcmpestri and pcmpestrm SSE4.2 instruction
321065  Valgrind updates for Xen 4.3
321148  Unhandled instruction: PLI (Thumb 1, 2, 3)
321363  Unhandled instruction: SSAX (ARM + Thumb)
321364  Unhandled instruction: SXTAB16 (ARM + Thumb)
321466  Unhandled instruction: SHASX (ARM + Thumb)
321467  Unhandled instruction: SHSAX (ARM + Thumb)
321468  Unhandled instruction: SHSUB16 (ARM + Thumb)
321619  Unhandled instruction: SHSUB8 (ARM + Thumb)
321620  Unhandled instruction: UASX (ARM + Thumb)
321621  Unhandled instruction: USAX (ARM + Thumb)
321692  Unhandled instruction: UQADD16 (ARM + Thumb)
321693  Unhandled instruction: LDRSBT (Thumb)
321694  Unhandled instruction: UQASX (ARM + Thumb)
321696  Unhandled instruction: UQSAX (Thumb + ARM)
321697  Unhandled instruction: UHASX (ARM + Thumb)
321703  Unhandled instruction: UHSAX (ARM + Thumb)
321704  Unhandled instruction: REVSH (ARM + Thumb)
321730  Add cg_diff and cg_merge man pages
321738  Add vgdb and valgrind-listener man pages
321814  == 315545
321891  Unhandled instruction: LDRHT (Thumb)
321960  pthread_create() then alloca() causing invalid stack write errors
321969  ppc32 and ppc64 don't support [lf]setxattr
322254  Show threadname together with tid if set by application
322294  Add initial support for IBM Power ISA 2.07
322368  Assertion failure in wqthread_hijack under OS X 10.8
322563  vex mips->IR: 0x70 0x83 0xF0 0x3A
322807  VALGRIND_PRINTF_BACKTRACE writes callstack to xml and text to stderr
322851  0bXXX binary literal syntax is not standard
323035  Unhandled instruction: LDRSHT(Thumb)
323036  Unhandled instruction: SMMLS (ARM and Thumb)
323116  The memcheck/tests/ppc64/power_ISA2_05.c fails to build [..]
323175  Unhandled instruction: SMLALD (ARM + Thumb)
323177  Unhandled instruction: SMLSLD (ARM + Thumb)
323432  Calling pthread_cond_destroy() or pthread_mutex_destroy() [..]
323437  Phase 2 support for IBM Power ISA 2.07
323713  Support mmxext (integer sse) subset on i386 (athlon)
323803  Transactional memory instructions are not supported for Power
323893  SSE3 not available on amd cpus in valgrind
323905  Probable false positive from Valgrind/drd on close()
323912  valgrind.h header isn't compatible for mingw64
324047  Valgrind doesn't support [LDR,ST]{S}[B,H]T ARM instructions
324149  helgrind: When pthread_cond_timedwait returns ETIMEDOUT [..]
324181  mmap does not handle MAP_32BIT
324227  memcheck false positive leak when a thread calls exit+block [..]
324421  Support for fanotify API on ARM architecture
324514  gdbserver monitor cmd output behaviour consistency [..]
324518  ppc64: Emulation of dcbt instructions does not handle [..]
324546  none/tests/ppc32 test_isa_2_07_part2 requests -m64
324582  When access is made to freed memory, report both allocation [..]
324594  Fix overflow computation for Power ISA 2.06 insns: mulldo/mulldo.
324765  ppc64: illegal instruction when executing none/tests/ppc64/jm-misc
324816  Incorrect VEX implementation for xscvspdp/xvcvspdp for SNaN inputs
324834  Unhandled instructions in Microsoft C run-time for x86_64
324894  Phase 3 support for IBM Power ISA 2.07
326091  drd: Avoid false race reports from optimized strlen() impls
326113  valgrind libvex hwcaps error on AMD64
n-i-bz  Some wrong command line options could be ignored
n-i-bz  patch to allow fair-sched on android
n-i-bz  report error for vgdb snapshot requested before execution
n-i-bz  same as 303624 (fixed in 3.8.0), but for x86 android

(3.9.0: 31 October 2013, vex r2796, valgrind r13707)

Re: [Valgrind-users] How to write a tool to check unsafe strcpy-alike functions in another way

[hamid a. <ham...@gm...>]

I wrote a function to return the size of an array in global memory. But I
am not sure if it works:

//return the size of a global block with a given address, 0 if not found
SizeT runtime_size_of_global(Addr adr)
{
    WordFM* gitree = giTree;
    GlobalTreeNode* g = find_GlobalTreeNode(gitree,adr);
    if(g)
        return g->szB;
    return 0;
}

How can my desired wrapper, which I am going to LD_PRELOAD, can have access
to this function in a way that it works?

Re: [Valgrind-users] Valgrind on Android Jelly Beans -- Can not launch app due to unrecognized instructions.

[John R. <jr...@Bi...>]

> I have 
> successfully built Valgrind as instructed in the README and pushed it into 
> my emulator. I used "android setprop wrap...." to redirect the app to be 
> launched through Valgrind, however, I am getting the following error for all 
> the apps launched by Valgrind:
> 
> ================from the logcat =================================
> I/val.sh  ( 1259): disInstr(thumb): unhandled instruction: 0xEEBA 0x7BEF
> I/val.sh  ( 1259): ==1260== valgrind: Unrecognised instruction at address 
> 0xcab86ad.
> I/val.sh  ( 1259): ==1260==    at 0xCAB86AC: ??? (in 
> /system/lib/libjavacore.so)

You forgot to say which version of valgrind (run "valgrind --version")
and which version of hardware (on Linux: "cat /proc/cpuinfo").

Assembling that unhandled Thumb-mode instruction 0xEEBA 0x7BEF:
----- foo.S
	.thumb_func
abc:
	.short 0xEEBA, 0x7BEF
-----
$ gcc -c foo.S
$ gdb foo.o
(gdb) x/i 1
   0x1 <abc+1>:	vcvt.f64.s32	d7, d7, #1
(gdb) x/x 0
0x0 <abc>:	0x7befeeba
-----

So does your hardware have vector floating point to execute 'vcvt.f64.s32' ?
The software believes (or was told) that the hardware does.  Is it true?
Check the configuration steps.  Look for a file "config.h", and see if
its contents describe your setup accurately.

-- 

[Valgrind-users] Valgrind on Android Jelly Beans -- Can not launch app due to unrecognized instructions.

[Jun Y. <YJ...@gm...>]

Hello everyone,

I am pretty new to both Valgrind and Android -- recently I am working on 
using Valgrind to check the running of some Android apps. I have 
successfully built Valgrind as instructed in the README and pushed it into 
my emulator. I used "android setprop wrap...." to redirect the app to be 
launched through Valgrind, however, I am getting the following error for all 
the apps launched by Valgrind:

================from the logcat =================================
I/val.sh  ( 1259): disInstr(thumb): unhandled instruction: 0xEEBA 0x7BEF
I/val.sh  ( 1259): ==1260== valgrind: Unrecognised instruction at address 
0xcab86ad.
I/val.sh  ( 1259): ==1260==    at 0xCAB86AC: ??? (in 
/system/lib/libjavacore.so)
I/val.sh  ( 1259): ==1260== Your program just tried to execute an 
instruction that Valgrind
I/val.sh  ( 1259): ==1260== 1. Your program has a bug and erroneously jumped 
to a non-code
I/val.sh  ( 1259): ==1260==    location.  If you are running Memcheck and 
you just saw a
I/val.sh  ( 1259): ==1260==    warning about a bad jump, it's probably your 
program's fault.
I/val.sh  ( 1259): ==1260== 2. The instruction is legitimate but Valgrind 
doesn't handle it,
I/val.sh  ( 1259): ==1260==    i.e. it's Valgrind's fault.  If you think 
this is the case or
I/val.sh  ( 1259): ==1260==    you are not sure, please let us know and 
we'll try to fix it.
I/val.sh  ( 1259): ==1260== Either way, Valgrind will now raise a SIGILL 
signal which will
I/val.sh  ( 1259): ==1260== probably kill your program.
I/val.sh  ( 1259): ==1260== Conditional jump or move depends on 
uninitialised value(s)
I/val.sh  ( 1259): ==1260==    at 0x4005224: ??? (in /system/bin/linker)
I/val.sh  ( 1259): ==1260== 
F/libc    ( 1260): Fatal signal 4 (SIGILL) at 0x0cadd8f0 (code=1), thread 
1260 (m.gstar.wponlyn)
I/val.sh  ( 1259): disInstr(thumb): unhandled instruction: 0xEEBA 0x7BEF
I/val.sh  ( 1259): ==1260== valgrind: Unrecognised instruction at address 
0xcab86ad.
I/val.sh  ( 1259): ==1260== valgrind: Unrecognised instruction at address 
0xcab86ad.
I/val.sh  ( 1259): ==1260==    at 0xCAB86AC: ??? (in 
/system/lib/libjavacore.so)
I/val.sh  ( 1259): ==1260== Your program just tried to execute an 
instruction that Valgrind
I/val.sh  ( 1259): ==1260== did not recognise.  There are two possible 
reasons for this.
I/val.sh  ( 1259): ==1260== 1. Your program has a bug and erroneously jumped 
to a non-code
I/val.sh  ( 1259): ==1260==    location.  If you are running Memcheck and 
you just saw a
I/val.sh  ( 1259): ==1260==    warning about a bad jump, it's probably your 
program's fault.
I/val.sh  ( 1259): ==1260== 2. The instruction is legitimate but Valgrind 
doesn't handle it,
I/val.sh  ( 1259): ==1260==    i.e. it's Valgrind's fault.  If you think 
this is the case or
I/val.sh  ( 1259): ==1260==    you are not sure, please let us know and 
we'll try to fix it.
I/val.sh  ( 1259): ==1260== Either way, Valgrind will now raise a SIGILL 
signal which will
I/val.sh  ( 1259): ==1260== probably kill your program.
I/val.sh  ( 1259): ==1260== 
I/val.sh  ( 1259): ==1260== Process terminating with default action of 
signal 4 (SIGILL)
I/val.sh  ( 1259): ==1260==  Illegal opcode at address 0xCAB86AD
I/val.sh  ( 1259): ==1260== Process terminating with default action of 
signal 4 (SIGILL)
I/val.sh  ( 1259): ==1260==  Illegal opcode at address 0xCAB86AD
I/val.sh  ( 1259): ==1260==    at 0xCAB86AC: ??? (in 
/system/lib/libjavacore.so)
I/val.sh  ( 1259): ==1260== 
I/val.sh  ( 1259): ==1260== HEAP SUMMARY:
I/val.sh  ( 1259): ==1260==     in use at exit: 344,162 bytes in 842 blocks
I/val.sh  ( 1259): ==1260==   total heap usage: 3,895 allocs, 3,053 frees, 
2,512,927 bytes allocated
I/val.sh  ( 1259): ==1260== 
D/dalvikvm( 1210): GC_FOR_ALLOC freed 422K, 8% free 5276K/5724K, paused 
591ms, total 802ms
I/val.sh  ( 1259): ==1260== LEAK SUMMARY:
I/val.sh  ( 1259): ==1260==    definitely lost: 2,618 bytes in 66 blocks
I/val.sh  ( 1259): ==1260==    indirectly lost: 26,528 bytes in 66 blocks
I/val.sh  ( 1259): ==1260==      possibly lost: 7,526 bytes in 180 blocks
I/val.sh  ( 1259): ==1260==    still reachable: 307,490 bytes in 530 blocks
I/val.sh  ( 1259): ==1260==         suppressed: 0 bytes in 0 blocks
I/val.sh  ( 1259): ==1260== Rerun with --leak-check=full to see details of 
leaked memory
I/val.sh  ( 1259): ==1260== 
I/val.sh  ( 1259): ==1260== Use --track-origins=yes to see where 
uninitialised values come from
I/val.sh  ( 1259): ==1260== ERROR SUMMARY: 9 errors from 3 contexts 
(suppressed: 0 from 0)

============================================================
after this point, the app is killed....

val.sh is the script that setprop used to launch app from valgrind.

Can anyone help me out with this weird behavior? Thanks!

Re: [Valgrind-users] How to write a tool to check unsafe strcpy-alike functions in another way

[hamid a. <ham...@gm...>]

Hi,
simply running valgrind with --tool=exp-sgcheck won't help, but the source
code definitely will. But what part of the code is handy?

I find that there are 2 related structs: StackBlock and GlobalBlock that
have a size field (szB). What is the function that convert a pointer to a
location in stack/global memory into related StackBlock/GlobalBlock struct?






On Thu, Oct 31, 2013 at 10:33 PM, Дмитрий Дьяченко <di...@gm...> wrote:

> Hi!
>
> exp-sgcheck can't help?
>
> Dmitry
>
> 2013/10/31 Philippe Waroquiers <phi...@sk...>:
> > On Thu, 2013-10-31 at 15:26 +0330, hamid alaei wrote:
> >> Hi everyone,
> >> Assume there is a C code that do this:
> >>
> >>
> >> char buff1[20];
> >> char buff2[30]="some small string";
> >> ...
> >>
> >> strcpy(buff1, buff2);
> >>
> >>
> >>
> >> This code is can be regarded unsafe not only because it use strcpy(),
> >> which doesn't accept a size argument for the maximum capacity of
> >> buff1, but also because the maximum capacity if the target string
> >> buff1 is less than the maximum capacity of the src string buff2.
> >>
> >> I know that if strcpy() tries to write outside buff1, then memcheck or
> >> sgcheck can detect that, depending on whether these strings are in
> >> stack/global memory or in the heap. But I want a warning while calling
> >> strcpy() in this manner as well, regardless of whether overflow
> >> happens or not.
> >>
> >>
> >> I am wondering if there is such a tool to do so. I guess it should
> >> replace strcpy() and similar functions with a wrapper. Does anybody
> >> know suck a tool/extension or how to write such a wrapper that can
> >> have access to the max-size of buff1 and buff2?
> >
> > This might be an interesting addition to e.g. memcheck
> > (or other tools that are replacing str* and others functions).
> >
> > I think this will be relatively easy to do for "simple cases"
> > of stack and global arrays, and maybe arrays in a stack/global struct :
> > using --read-var-info=yes, valgrind provides access to (some)
> > information about theses, (and from a small experiment, it looks
> > like it knows the size of these).
> >
> > However, for more complex cases (e.g. arrays in a dynamically allocated
> > struct), this will be more complex: how to guess (or keep track) that a
> > pointer inside a block is a pointer to an array smaller than
> > the malloc-ed block is unclear to me.
> >
> > Philippe
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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.clktrk
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] How to write a tool to check unsafe strcpy-alike functions in another way

[Дмитрий Д. <di...@gm...>]

Hi!

exp-sgcheck can't help?

Dmitry

2013/10/31 Philippe Waroquiers <phi...@sk...>:
> On Thu, 2013-10-31 at 15:26 +0330, hamid alaei wrote:
>> Hi everyone,
>> Assume there is a C code that do this:
>>
>>
>> char buff1[20];
>> char buff2[30]="some small string";
>> ...
>>
>> strcpy(buff1, buff2);
>>
>>
>>
>> This code is can be regarded unsafe not only because it use strcpy(),
>> which doesn't accept a size argument for the maximum capacity of
>> buff1, but also because the maximum capacity if the target string
>> buff1 is less than the maximum capacity of the src string buff2.
>>
>> I know that if strcpy() tries to write outside buff1, then memcheck or
>> sgcheck can detect that, depending on whether these strings are in
>> stack/global memory or in the heap. But I want a warning while calling
>> strcpy() in this manner as well, regardless of whether overflow
>> happens or not.
>>
>>
>> I am wondering if there is such a tool to do so. I guess it should
>> replace strcpy() and similar functions with a wrapper. Does anybody
>> know suck a tool/extension or how to write such a wrapper that can
>> have access to the max-size of buff1 and buff2?
>
> This might be an interesting addition to e.g. memcheck
> (or other tools that are replacing str* and others functions).
>
> I think this will be relatively easy to do for "simple cases"
> of stack and global arrays, and maybe arrays in a stack/global struct :
> using --read-var-info=yes, valgrind provides access to (some)
> information about theses, (and from a small experiment, it looks
> like it knows the size of these).
>
> However, for more complex cases (e.g. arrays in a dynamically allocated
> struct), this will be more complex: how to guess (or keep track) that a
> pointer inside a block is a pointer to an array smaller than
> the malloc-ed block is unclear to me.
>
> Philippe
>
>
>
>
> ------------------------------------------------------------------------------
> 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.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How to write a tool to check unsafe strcpy-alike functions in another way

[hamid a. <ham...@gm...>]

:) thanks Philippe. I realized you are a Valgrind developer. I may not be
able to do that implementation. But out of curiosity, if someone does that
for static arrays, I guess he/she should have access to some DWARF3
information that is already decoded by valgrind (I guess). So where should
he/she finds the decoded DWARF3 data structures and related functions in
the valgrind source code? Are they easy to work with? What is the
complexity of that part of valgrind?


On Thu, Oct 31, 2013 at 9:48 PM, hamid alaei <ham...@gm...> wrote:

> :) thanks Philippe. I realized you are a Valgrind developer. I may not be
> able to do that implementation. But out of curiosity, if someone does that
> for static arrays, I guess he/she should have access to some DWARF3
> information that is already decoded by valgrind (I guess). So where should
> he/she finds the decoded DWARF3 data structures and related functions in
> the valgrind source code? Are they easy to work with? What is the
> complexity of that part of valgrind?
>
>
> On Thu, Oct 31, 2013 at 9:38 PM, Philippe Waroquiers <
> phi...@sk...> wrote:
>
>> (I have re-replied on the list)
>>
>> On Thu, 2013-10-31 at 19:05 +0100, Philippe Waroquiers wrote:
>> > On Thu, 2013-10-31 at 21:00 +0330, hamid alaei wrote:
>> > > Thanks Philippe,
>> > >
>> > > I know that can be an interesting extension. I also hope that to
>> > > Valgrind developers doing so can be easy. For dynamically allocated
>> > > structs, I just expected a tool that can detect if the size of a hole
>> > > block/struct is large enough, not specifically one of its static array
>> > > fields. I think that work well in many cases. However, there should be
>> > > a way to implement such a runtime type checking as well: it will be
>> > > easy in the case of using new operator in C++. With malloc as well the
>> > > desired tool can guess the type of block by observing the type of
>> > > pointers in which the address of the block is stored after malloc.
>> > "observing the type of pointers ..." is what I think is complex/unclear
>> > how to do.
>> >
>> > >
>> > >
>> > > But the question here is how we can ask valgrind developers to kindly
>> > > implement such an extension. It will be very hard to me to do so and I
>> > > hope no one force me to do that!!!
>> > At least for the easy cases, that would be an interesting thing (not so
>> > difficult) to look at for a first hack on valgrind.
>> > Nobody will of course force you :).
>> >
>> > Philippe
>> >
>> >
>> >
>>
>>
>>
>

Re: [Valgrind-users] How to write a tool to check unsafe strcpy-alike functions in another way

[Philippe W. <phi...@sk...>]

On Thu, 2013-10-31 at 21:31 +0330, hamid alaei wrote:

> -----------------------------------------------------------------------
> 3- Reply to Philippe:
> 
> -----------------------------------------------------------------------
> Thanks Philippe,
> 
> I know that can be an interesting extension. I also hope that to
> Valgrind developers doing so can be easy. For dynamically allocated
> structs, I just expected a tool that can detect if the size of a hole
> block/struct is large enough, not specifically one of its static array
> fields. I think that work well in many cases. However, there should be
> a way to implement such a runtime type checking as well: it will be
> easy in the case of using new operator in C++. With malloc as well the
> desired tool can guess the type of block by observing the type of
> pointers in which the address of the block is stored after malloc.
"observing the type of pointers ..." is what I think is complex/unclear
how to do.
> 
> 
> But the question here is how we can ask valgrind developers to kindly
> implement such an extension. It will be very hard to me to do so and I
> hope no one force me to do that!!!
At least for the easy cases, that would be an interesting thing (not so
difficult) to look at for a first hack on valgrind.
Nobody will of course force you :).

Philippe

Re: [Valgrind-users] How to write a tool to check unsafe strcpy-alike functions in another way

[hamid a. <ham...@gm...>]

OMG, I find that I did not reply to mailing list. So here is my replies to
those how kindle replied me ;)
-----------------------------------------------------------------------
1- Reply to Bart
-----------------------------------------------------------------------
Thanks, but it says it is a static tool, therefore cannot work for dynamic
arrays or even for input argument of a function. My problem is that static
tools generate too much errors and dynamic tools like valgrind may not find
a bug if the test have poor coverage, which almost always is the case. So I
need something in between.
-----------------------------------------------------------------------
2- Reply to Bard
-----------------------------------------------------------------------
Ideally, I am thinking of a function, let say RUNTIME_SIZEOF(x) that gives
the size of object x at runtime, no matter if it is a local or global or
heap variable. Having such a function in valgrind library, then one can
simply write a wrapper for every function like strcpy:

*#include <stdio.h>*
* *

*#include "valgrind.h"*
* *

*char *I_WRAP_SONAME_FNNAME_ZU(???,**strcpy)(char *buff1, char *buff2)*
* *

*{*
* *

*       char * result;*
* *

*       OrigFn fn;*
* *

*       VALGRIND_GET_ORIG_FN(fn);*

*       if(RUNTIME_SIZEOF(buff1) < RUNTIME_SIZEOF(buff2))*

*       {*

*               printf("SOME ERROR REPORT");
*

*       }
*
* *

*       CALL_FN_W_WW(result, buff1, buff2); *
*       return result;
}*
-----------------------------------------------------------------------
3- Reply to Philippe:
-----------------------------------------------------------------------
Thanks Philippe,
I know that can be an interesting extension. I also hope that to Valgrind
developers doing so can be easy. For dynamically allocated structs, I just
expected a tool that can detect if the size of a hole block/struct is large
enough, not specifically one of its static array fields. I think that work
well in many cases. However, there should be a way to implement such a
runtime type checking as well: it will be easy in the case of using new
operator in C++. With malloc as well the desired tool can guess the type of
block by observing the type of pointers in which the address of the block
is stored after malloc.

But the question here is how we can ask valgrind developers to kindly
implement such an extension. It will be very hard to me to do so and I hope
no one force me to do that!!!
-----------------------------------------------------------------------
Thanks all

Re: [Valgrind-users] How to write a tool to check unsafe strcpy-alike functions in another way

[Philippe W. <phi...@sk...>]

On Thu, 2013-10-31 at 15:26 +0330, hamid alaei wrote:
> Hi everyone,
> Assume there is a C code that do this:
> 
> 
> char buff1[20];
> char buff2[30]="some small string";
> ...
> 
> strcpy(buff1, buff2);
> 
> 
> 
> This code is can be regarded unsafe not only because it use strcpy(),
> which doesn't accept a size argument for the maximum capacity of
> buff1, but also because the maximum capacity if the target string
> buff1 is less than the maximum capacity of the src string buff2.
> 
> I know that if strcpy() tries to write outside buff1, then memcheck or
> sgcheck can detect that, depending on whether these strings are in
> stack/global memory or in the heap. But I want a warning while calling
> strcpy() in this manner as well, regardless of whether overflow
> happens or not.
> 
> 
> I am wondering if there is such a tool to do so. I guess it should
> replace strcpy() and similar functions with a wrapper. Does anybody
> know suck a tool/extension or how to write such a wrapper that can
> have access to the max-size of buff1 and buff2?

This might be an interesting addition to e.g. memcheck
(or other tools that are replacing str* and others functions).

I think this will be relatively easy to do for "simple cases"
of stack and global arrays, and maybe arrays in a stack/global struct :
using --read-var-info=yes, valgrind provides access to (some)
information about theses, (and from a small experiment, it looks
like it knows the size of these).

However, for more complex cases (e.g. arrays in a dynamically allocated
struct), this will be more complex: how to guess (or keep track) that a
pointer inside a block is a pointer to an array smaller than
the malloc-ed block is unclear to me.

Philippe

Re: [Valgrind-users] Running massif on code with custom allocator with non-malloc-like API

[Philippe W. <phi...@sk...>]

On Thu, 2013-10-31 at 14:06 +0400, Konstantin Tokarev wrote:
> Hi all,
> 
> I'm trying to use massif to analyze memory usage of WebKit. I build it without embedded tcmalloc, so 
> "normal" heap allocations are traced by massif. However, its JavaScript engine still uses separate 
> mmap-based heap. How can I trace allocations made in this heap with massif? API is not malloc-like, 
> so I guess I need to write some code to get this functions replaced in Valgrind.
> 
> P.S. I've tried --pages-as-heap=yes to trace mmap directly, but results were completely garbage.
> 
massif supports the client requests VALGRIND_MALLOCLIKE_BLOCK,
VALGRIND_RESIZEINPLACE_BLOCK and  VALGRIND_FREELIKE_BLOCK.
Inserting calls to these inside the JavaScript engine where it
allocates, re-allocates and frees blocks should allow to describe
memory usage by the JavaScript engine.

Pḧilippe

Re: [Valgrind-users] How to write a tool to check unsafe strcpy-alike functions in another way

[Bart V. A. <bva...@ac...>]

On 31/10/2013 4:56, hamid alaei wrote:
> Hi everyone,
> Assume there is a C code that do this:
>
> char buff1[20];
> char buff2[30]="some small string";
> ...
> strcpy(buff1, buff2);
>
> This code is can be regarded unsafe not only because it use strcpy(),
> which doesn't accept a size argument for the maximum capacity of buff1,
> but also because the maximum capacity if the target string buff1 is less
> than the maximum capacity of the src string buff2.
>
> I know that if strcpy() tries to write outside buff1, then memcheck or
> sgcheck can detect that, depending on whether these strings are in
> stack/global memory or in the heap. But I want a warning while calling
> strcpy() in this manner as well, regardless of whether overflow happens
> or not.
>
> I am wondering if there is such a tool to do so. I guess it should
> replace strcpy() and similar functions with a wrapper. Does anybody know
> suck a tool/extension or how to write such a wrapper that can have
> access to the max-size of buff1 and buff2?

Hello Hamid,

I think that smatch is already able to detect for the above example that 
the output buffer is too small (http://smatch.sourceforge.net/).

Bart.

[Valgrind-users] How to write a tool to check unsafe strcpy-alike functions in another way

[hamid a. <ham...@gm...>]

Hi everyone,
Assume there is a C code that do this:

char buff1[20];
char buff2[30]="some small string";
...
strcpy(buff1, buff2);

This code is can be regarded unsafe not only because it use strcpy(), which
doesn't accept a size argument for the maximum capacity of buff1, but also
because the maximum capacity if the target string buff1 is less than the
maximum capacity of the src string buff2.

I know that if strcpy() tries to write outside buff1, then memcheck or
sgcheck can detect that, depending on whether these strings are in
stack/global memory or in the heap. But I want a warning while calling
strcpy() in this manner as well, regardless of whether overflow happens or
not.

I am wondering if there is such a tool to do so. I guess it should replace
strcpy() and similar functions with a wrapper. Does anybody know suck a
tool/extension or how to write such a wrapper that can have access to the
max-size of buff1 and buff2?

Regards,
Hamid.

[Valgrind-users] Running massif on code with custom allocator with non-malloc-like API

[Konstantin T. <an...@ya...>]

Hi all,

I'm trying to use massif to analyze memory usage of WebKit. I build it without embedded tcmalloc, so "normal" heap allocations are traced by massif. However, its JavaScript engine still uses separate mmap-based heap. How can I trace allocations made in this heap with massif? API is not malloc-like, so I guess I need to write some code to get this functions replaced in Valgrind.

P.S. I've tried --pages-as-heap=yes to trace mmap directly, but results were completely garbage.

-- 
Regards,
Konstantin

Re: [Valgrind-users] Valgrind apparently looping after long test run

[Tim B. <ti...@va...>]

On 10/30/2013 06:50 AM, Philippe Waroquiers wrote:
> All the above is caused by the internal Valgrind kitchen.
> In particular, the pipes are used to implement a lock.
> The write is an "unlock" and the read is a "lock".

I see. Thanks very much for explaining. It certainly did look unusual.
I'm quickly getting a sense of what's under the hood in Valgrind... a
lot more than I thought.

> NB: just for my own info, why are you using --vgdb=no ?
> Any problems with it ?

I'm not exactly sure at this point. It was added to the test script
quite some time ago. It may just be there to suppress the informational
messages from Valgrind saying how to debug the program.

By the way, I was able to find the problem in our software with a good
amount of luck and by progressively whittling down the test. It
uncovered an unconsidered corner case in some code that goes back ten
years. Thanks!

Tim

Re: [Valgrind-users] Valgrind apparently looping after long test run

[Philippe W. <phi...@sk...>]

On Tue, 2013-10-29 at 10:24 +0900, Tim Burress wrote:
> I'm using Valgrind 3.8.1 to run fuzzing tests on control software for an
> embedded system. The tests are run on
> 
> Linux pod 3.11.4-201.fc19.x86_64 #1 SMP Thu Oct 10 14:11:18 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux
> 
> Valgrind itself is the standard Fedora 19 build with the following
> arguments:
> 
> valgrind	-v --leak-check=full
> 		--leak-resolution=high
> 		--show-possibly-lost=yes
> 		--track-fds=yes
> 		--num-callers=24
> 		--vgdb=no
> 
> Normally all this works fine, but last night I did an overnight run on a
> new dataset and after about eight hours valgrind started looping. I
> wasn't sure what to do about that... there were no diagnostics either
> from my software or from valgrind. When I attached to the program with
> strace I got this endless series:
> 
> clock_gettime(CLOCK_MONOTONIC, {124051, 458677331}) = 0
> rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
> rt_sigtimedwait([HUP INT ILL BUS FPE KILL SEGV TERM STOP WINCH SYS RTMIN
> RT_1], 0x4028a5e30, {0, 0}, 8) = -1 EAGAIN (Resource temporarily
> unavailable)
> rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
> gettid()                                = 30464
> gettid()                                = 30464
> write(1029, "A", 1)                     = 1
> gettid()                                = 30464
> read(1028, "A", 1)                      = 1
> gettid()                                = 30464
> clock_gettime(CLOCK_MONOTONIC, {124051, 469072047}) = 0
> rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
> rt_sigtimedwait([HUP INT ILL BUS FPE KILL SEGV TERM STOP WINCH SYS RTMIN
> RT_1], 0x4028a5e30, {0, 0}, 8) = -1 EAGAIN (Resource temporarily
> unavailable)
> rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
> gettid()                                = 30464
> gettid()                                = 30464
> write(1029, "B", 1)                     = 1
> gettid()                                = 30464
> read(1028, "B", 1)                      = 1
> gettid()
> 
> It loops through the English alphabet, one letter at a time, uppercase A
> to uppercase Z, and then repeats. TID 30464 is the PID of the valgrind
> process. File descriptors 1028 and 1029 appear to be the opposite ends
> of a pipe, but I have no idea why the alphabet would be cycling through
> it. The sigtimedwait() call is polling for one of those signals and not
> getting it. We have no such calls explicitly in our code, and no RT
> calls at all, which leads me to think this is valgrind's internal code,
> but of course it could still be measuring something within the main program.
All the above is caused by the internal Valgrind kitchen.
In particular, the pipes are used to implement a lock.
The write is an "unlock" and the read is a "lock".

> 
> I ran gstack on it but got only:
> 
> gstack 30464
> #0  0x0000000038033cb0 in vgMemCheck_helperc_LOADV64le ()
> #1  0x0000000403290318 in ?? ()
> #2  0x00000004028a5f00 in ?? ()
> #3  0x0000000000000000 in ?? ()
> 
> which doesn't tell me a whole lot, and I don't find vgMemCheck_helperc
> anywhere in the code, so I guess it's something synthesized at compile time.
What you observe above is the host stack trace executing the guest code.
All the above indicates Valgrind is (still) executing the application
code.
Valgrind is (normally) compiled with -g. But in any case, if it was not
(or the Valgrind debug info was not installed on your fedora), this will
not help to get an understandable guest stack trace.

Rather, do not use --vgdb=no, rather keep the default (--vgdb=yes)
or use --vgdb=full (if needed).


You can then use gdb+vgdb to debug your application running under
Valgrind and see e.g. what your application is doing.

For more information look at Valgrind user manual section
3.2. Debugging your program using Valgrind gdbserver and GDB
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver

Philippe
NB: just for my own info, why are you using --vgdb=no ?
Any problems with it ?

Re: [Valgrind-users] Dynamic analysis with given input

[Josef W. <Jos...@gm...>]

Am 29.10.2013 03:27, schrieb Loi Luu:
> supports many useful tools. I'm thinking to use *Callgrind *to solve my
> problem, but I'm not sure whether its a right choice.

Callgrind does observe branch behavior, and counts how often
instructions from various branches are executed.

The source annotation may already be enough for you, but
it gives more details to see it at instruction level, and
also see the jump behavior.
For that, check out the callgrind options
 "--dump-instr=yes --collect-jumps=yes",
and look at the machine code annotation in KCachegrind.

Not sure this is really what you want.

Josef


 Could you please
> give me some suggestion? Is this a possible approach and how can I
> process this way?
> 
> Thank you,
> 
> -- 
> 
> Loi, Luu The (Mr.)
> RA at Security Lab, SoC, NUS
> 
> 
> ------------------------------------------------------------------------------
> 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.clktrk
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

[Valgrind-users] Dynamic analysis with given input

[Loi L. <loi...@gm...>]

Hi,


I have a C program and I want to track all branch conditions which belong
to an execution path corresponding to a concrete input. For example,
consider a simple program:

#include <stdio.h>
#include <string.h>
int test(char* a) {
    if (strcmp(a, "123") == 0)
       return 0;

    if (strcmp(a, "123") < 0)
       return -1;
    else
       return 1;
  }

   int main() {
      char* a;
      return test (a);
  }

With a = "1234", the program return 1 and the corresponding path condition
is strcmp(a, "123") > 0. I want to collect strcmp, "123" and value of this
operator (1). I first thought about working with some C parser but seems
like its not that simple. To get the values of parameters we have to deal
with pointer analysis or external library call, which I don't know how to
solve.

Then I made several searches and come to valgrind. I read around the
documentation and tool description. It's so expressive that valgrind
supports many useful tools. I'm thinking to use *Callgrind *to solve my
problem, but I'm not sure whether its a right choice. Could you please give
me some suggestion? Is this a possible approach and how can I process this
way?

Thank you,

-- 
Loi, Luu The (Mr.)
RA at Security Lab, SoC, NUS