I get this in Valgrind.
--24101-- REDIR: 0xbb20580 (operator delete(void*)) redirected to 0x93b7d48 (operator delete(void*))
--24101-- REDIR: 0xbb22580 (operator new[](unsigned long)) redirected to 0x93b88b7 (operator new[](unsigned long))
==24101== WARNING: new redirection conflicts with existing -- ignoring it
--24101-- new: 0x15632010 (__GI_strlen ) R-> 0x093b96b0 strlen
--24101-- REDIR: 0xbb205c0 (operator delete[](void*)) redirected to 0x93b79c4 (operator delete[](void*))
Is it any concern?
A big part of Valgrind's magic is how it is able to intercept/redirect function calls in order to keep track of the state of the world.
As I understand it, redirection is achieved using shared object/function name patterns which when matched 'redirect' calls to new addresses. Checking out the valgrind source, we find the notion of a 'redirector':
The redirector holds two pieces of state:
Specs - a set of (soname pattern, fnname pattern) -> redir addr
Active - a set of orig addr -> (bool, redir addr)
(m_redir.c line 104)
So 'Specs' provide shared object/function name to address mappings and 'Actives' represent the mappings themselves.
Active computation:
Active = empty
for spec in Specs {
sopatt = spec.soname pattern
fnpatt = spec.fnname pattern
redir = spec.redir addr
for so matching sopatt in SyminfoState {
for fn matching fnpatt in fnnames_of(so) {
&fn -> redir is added to Active
}
}
}
(m_redir.c line 120)
The idea of "conflicting redirections" is mentioned here too:
Clearly we must impose the requirement that domain(Active) contains
no duplicates. The difficulty is how to constrain Specs enough to
avoid getting into that situation. It's easy to write specs which
could cause conflicting bindings in Active, eg:
(libpthread.so, pthread_mutex_lock) -> a1
(libpthread.so, pthread_*) -> a2
for a1 != a2. Or even hairier:
(libpthread.so, pthread_mutex_*) -> a1
(libpthread.so, pthread_*_lock) -> a2
(m_redir.c line 152)
And for interests sake, here is where your warning is generated:
old = VG_(OSetGen_Lookup)( activeSet, &act.from_addr );
if (old) {
/* Dodgy. Conflicting binding. */
vg_assert(old->from_addr == act.from_addr);
if (old->to_addr != act.to_addr) {
/* we have to ignore it -- otherwise activeSet would contain
conflicting bindings. */
what = "new redirection conflicts with existing -- ignoring it";
goto bad;
}
(m_redir.c line 664)
So, after all this it is probably safe to assume that:
References: Valgrind manual, Valgrind 3.6.1 source
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With