|
From: Wayne A. <Way...@au...> - 2012-09-09 00:21:25
|
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 (moc...@x8...) (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
|