When using valgrind 3.7.0 on my application, valgrind runs fine
I just tried a local build of 3.8.0 from svn today.
the application is hitting an assert in debuginfo.c line info addresses out
of order
==24227== Memcheck, a memory error detector
==24227== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==24227== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==24227== Command: optim/runTime/bin/maya.bin -prompt
==24227== Parent PID: 22486
==24227==
--24227--
--24227-- Valgrind options:
--24227-- --tool=memcheck
--24227-- --db-attach=no
--24227-- --suppressions=/u/warnold/maya.supp
--24227-- --error-limit=no
--24227-- --num-callers=40
--24227-- --leak-check=yes
--24227-- --leak-resolution=high
--24227-- --show-reachable=yes
--24227-- --trace-children=no
--24227-- --log-file=/u/warnold/val.%p.txt
--24227-- --malloc-fill=ac
--24227-- --free-fill=fe
--24227-- --track-origins=yes
--24227-- -v
--24227-- -v
--24227-- -v
--24227-- Contents of /proc/version:
--24227-- Linux version 3.4.4-5.fc17.x86_64
(mockbu...@x86-02.phx2.fedoraproject.org) (gcc version 4.7.0 201205
07 (Red Hat 4.7.0-5) (GCC) ) #1 SMP Thu Jul 5 20:20:59 UTC 2012
--24227-- Arch and hwcaps: AMD64, amd64-sse3-cx16
--24227-- Page sizes: currently 4096, max supported 4096
--24227-- Valgrind library directory: /opt/valgrind380svn/lib/valgrind
--24227-- TT/TC: VG_(init_tt_tc) (startup of code management)
--24227-- TT/TC: cache: 8 sectors of 27597024 bytes each = 220776192 total
--24227-- TT/TC: table: 524168 total entries, max occupancy 340704 (65%)
==24227== Adding active redirection:
--24227-- new: 0xffffffffff600000 (??? ) R-> (0000.0)
0x3806b803 ???
==24227== Adding active redirection:
--24227-- new: 0xffffffffff600400 (??? ) R-> (0000.0)
0x3806b80d ???
==24227== Adding active redirection:
--24227-- new: 0xffffffffff600800 (??? ) R-> (0000.0)
0x3806b817 ???
--24227-- Reading syms from
/home/warnold/branch/main/build/optim/runTime/bin/maya.bin
--24227-- svma 0x000040bc70, avma 0x000040bc70
--24227-- Considering
/home/warnold/branch/main/build/optim/runTime/bin/maya.bin.debug ..
--24227-- .. CRC is valid
--24227-- Reading syms from
/opt/valgrind380svn/lib/valgrind/memcheck-amd64-linux
...
--24227-- Reading syms from
/home/warnold/branch/main/build/optim/runTime/lib/libFoundation.so
--24227-- svma 0x00001165f0, avma 0x00063745f0
--24227-- Considering
/home/warnold/branch/main/build/optim/runTime/lib/libFoundation.so.debug ..
--24227-- .. CRC is valid
--24227-- summarise_context(loc_start = 0x36f): cannot summarise(why=2):
0x370: [0]={ 32(r7) { u u u u u u r6 u u u u u u c-24 u c-16 c-8 u
u u }
--24227-- summarise_context(loc_start = 0x370): cannot summarise(why=2):
...
0xee: [0]={ 352(r7) { u u u r3 u u r6 u u u u u r12 r13 r14 r15 c-8 u
u u }
--24227-- summarise_context(loc_start = 0xee): cannot summarise(why=2):
0xef: [0]={ 8(r7) { u u u r3 u u r6 u u u u u r12 r13 r14 r15 c-8 u
u u }
--24227-- warning: line info addresses out of order at entry 0: 0x63c9178
0x63c8e10
valgrind: m_debuginfo/debuginfo.c:1286 (vgModuleLocal_find_rx_mapping):
Assertion 'lo <= hi' failed.
==24227== at 0x3805560F: report_and_quit (m_libcassert.c:235)
==24227== by 0x38055752: vgPlain_assert_fail (m_libcassert.c:309)
==24227== by 0x3807F283: vgModuleLocal_find_rx_mapping (debuginfo.c:1286)
==24227== by 0x380897C1: vgModuleLocal_addLineInfo (storage.c:388)
==24227== by 0x380D5C91: vgModuleLocal_read_debuginfo_dwarf3
(readdwarf.c:378)
==24227== by 0x38085041: vgModuleLocal_read_elf_debug_info (readelf.c:2531)
==24227== by 0x3807E295: vgPlain_di_notify_mmap (debuginfo.c:628)
==24227== by 0x3809F9B8: vgModuleLocal_generic_PRE_sys_mmap
(syswrap-generic.c:2066)
==24227== by 0x380C8654: vgSysWrap_amd64_linux_sys_mmap_before
(syswrap-amd64-linux.c:1012)
==24227== by 0x3809C505: vgPlain_client_syscall (syswrap-main.c:1451)
==24227== by 0x3809921F: handle_syscall (scheduler.c:1057)
==24227== by 0x3809A796: vgPlain_scheduler (scheduler.c:1335)
==24227== by 0x380AA289: run_a_thread_NORETURN (syswrap-linux.c:103)
the output is marked as a warning, but the assertion then kills the run.
commenting out the assertion appears to let the app continue without issue
Is the assertion important that it can't continue ?
this looks like new code
Thanks
--
Wayne Arnold
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
