Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Valgrind and "WARNING: new redirection conflicts with existing"

Tags:

c++

valgrind

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?

like image 864
Anycorn Avatar asked Jul 23 '11 23:07

Anycorn


1 Answers

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:

  1. The redirection messages are part of normal valgrind operation.
  2. The warning message is likely a result of conflicting spec patterns (probably not a great cause for concern in this instance.)

References: Valgrind manual, Valgrind 3.6.1 source

like image 124
Jesse Avatar answered Sep 20 '22 22:09

Jesse