--trace-redir=yes shows that there are duplicated redir entries e.g.
--32537-- TOPSPECS of soname NONE filename /home/philippe/valgrind/m_redir_trace/memcheck/vgpreload_memcheck-amd64-linux.so
--32537-- libc.so* strcasecmp_l R-> (2014.0) 0x04c28bf0
--32537-- libc.so* strcasecmp_l R-> (2014.0) 0x04c28bf0
--32537-- libc.so* __GI_strcasecmp_l R-> (2014.0) 0x04c28b70
--32537-- libc.so* __GI_strcasecmp_l R-> (2014.0) 0x04c28b70
These are caused by the merging of identical debug entries always
adding the two primary names, even if the entries are exactly the same.
This patch avoids duplicated names in debug info if the entry to merge
has only one name identical to the entry name to which we are merging.
This avoids the useless duplicated redir entries, and slightly decreases
the "dinfo" memory usage.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12554
di->soname was not freed, so was leaked when debug info is removed.
free(soname) added in free_Debuginfo, after having verified
and then ensured that all soname are allocated in dinfo.
regtested on deb6/amd64
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12442
(found by running regression tests with an outer memcheck).
(validated by running all regression tests "natively" on x86 and amd64,
and re-running regressions tests with outer memcheck).
==7500== 160 bytes in 2 blocks are definitely lost in loss record 75 of 246
==7500== at 0x2803CEF7: vgPlain_arena_malloc (m_mallocfree.c:1599)
==7500== by 0x280AAFA5: vgModuleLocal_dinfo_zalloc (misc.c:48)
==7500== by 0x2804E2A4: vgPlain_newXA (m_xarray.c:68)
==7500== by 0x280B3CD6: unitary_range_list (readdwarf3.c:703)
==7500== by 0x280B66CF: parse_var_DIE (readdwarf3.c:1631)
==7500== by 0x280BA0A6: read_DIE (readdwarf3.c:3248)
==7500== by 0x280BA170: read_DIE (readdwarf3.c:3269)
==7500== by 0x280BABC4: T.364 (readdwarf3.c:3611)
==7500== by 0x280BC634: vgModuleLocal_new_dwarf3_reader (readdwarf3.c:4035)
==7500== by 0x280609F4: vgModuleLocal_read_elf_debug_info (readelf.c:2529)
==7500== by 0x2805BD31: vgPlain_di_notify_mmap (debuginfo.c:610)
==7500== by 0x280362E3: valgrind_main (m_main.c:1944)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12419
Previously it looked for the debuginfo object for "/system/X" in
"/sdcard/symbols/system/X". This commit removes the requirement for
"system" as the first path component, so the mapping is now "/X" (viz,
any absolute path) to "/sdcard/symbols/X".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12406
functions that do FP arithmetic. This is due to the Dwarf3 CFI
mentioning Dwarf registers above N_CFI_REGS, in particular FP
registers, which have values of about 80. This fixes the problem by
increasing N_CFI_REGS to a level that covers all known registers.
(n-i-bz)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12393
(Rusty Russell, rusty@rustcorp.com.au)
tdb uses fcntl locks and mmap, and some of the tests fail under valgrind.
strace showed valgrind opening the tdb file, reading 1024 bytes, then closing
it. This is not allowed: POSIX says if you open and close a file, all fcntl
locks on it are dropped (insane, yes).
Finally got around to hacking the source to track this down: di_notify_mmap is
doing the damage. The simplest fix was to hand in an optional fd for it to
use, then have it do pread.
I had to fix your pread; surely this should seek back even if the platform
doesn't have pread support?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12224
and use read_Type routines instead as they work rather better on strict
aligned (or semi-strict a la ARM) machines. Fixes#282527.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12083
confusing control flow, by separating the logic for "is there a
debuginfo file to be found?" from that of "if a debuginfo file was
found, let's record certain facts (section offsets etc) about it."
This makes it possible to add arbitrary other schemes for finding
debuginfo files without further complicating the existing control flow.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12056
10% reduction in debuginfo storage requirements for large applications
on 32 bit platforms. This code had been present since the MacOSX port
was merged but had been disabled. Remove equivalent code for
shrinking the symbol tables since they are much (4 x) smaller than the
line number tables, trimming them is hardly worth the effort.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12050
* configure.in support
* new supp file darwin11.supp
* comment out many intercepts in mc_replace_strmem.c and
vg_replace_malloc.c that are apparently unnecessary for Darwin
* add minimal handling for the following new syscalls and mach traps:
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
* wqthread_hijack on amd64-darwin: deal with
tst->os_state.pthread having an apparently different offset,
which caused an assertion failure
* m_debuginfo: for 32 bit processes on Lion, use the DebugInfoFSM
cleanup added in r12041/12042 to handle apparently new dyld
behaviour, which is to map text areas r-- first and only
vm_protect them later to r-x.
The following cleanups remain to be done
* remove apparently pointless, commented out wrapper macro
invokations in mc_replace_strmem.c, eg
//MEMMOVE(VG_Z_DYLD, memmove)
(or determine that they are still necessary, and uncomment)
* ditto in vg_replace_malloc.c, plus general VGO_darwin cleanups
there
* write proper syscall wrappers for
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
These are currently just no-ops and may be causing Memcheck to
report false undef-value errors
* figure out why it doesn't work properly unless built with gcc-4.2 on
Lion.
gcc-4.2 is the "normal" gcc (i686-apple-darwin11-gcc-4.2.1). Plain
gcc is the hybrid gcc-front-end clang-back-end thing
(i686-apple-darwin11-llvm-gcc-4.2). Whereas on Snow Leopard, plain
gcc is the normal gcc.
The symptoms of the failure are that wqthread_hijack in
syswrap-amd64-linux.c hits this /*NOTREACHED*/ vg_assert(0); right
at the end (you need a pretty complex threaded app to trigger this),
which makes me think that either ML_(wqthread_continue_NORETURN) or
call_on_new_stack_0_1 do return, which they are not expected to.
* figure out if some of the uninitialised value errors reported in
system libraries on are caused by Memcheck being confused by LLVM
generated code, as per bug #242137
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12043
contains a bunch of fields which are used as a very simple state
machine that observes mmap calls and decides when to read debuginfo
for the associated file. This change moves these fields into their
own structure, struct _DebugInfoFSM, for cleanness, so as to make it
clear they have a common purpose.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12041
macro, set di->soname back to NULL, so that if we later reenter with
the same 'di', we don't fall over the initial di->soname == NULL
assertion.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12023
