C++/Valgrind REDIR

Question

Lo entiendo en 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*)) 

¿Es alguna preocupación?

Answer 1

Una gran parte de la magia de Valgrind es cómo es capaz de interceptar/redirigir las llamadas de función con el fin de realizar un seguimiento del estado del mundo.

Según tengo entendido, la redirección se logra utilizando patrones de nombre de objeto/función compartidos que cuando se combinan llamadas 'redireccionar' a direcciones nuevas. La salida a la fuente valgrind, nos encontramos con la noción de un 'redireccionamiento':

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) 

(línea m_redir.c 104)

Así 'Especificaciones' proporcionar compartida nombre del objeto/función para hacer frente a las asignaciones y 'Activos 'representan las asignaciones en sí.

cálculo activa:

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 
     } 
    } 
} 

(línea m_redir.c 120)

La idea de "cambios de dirección en conflicto" se menciona aquí también:

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 

(línea 152 m_redir.c)

Y por los intereses, aquí es donde se genera su advertencia:

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; 
    } 

(línea m_redir.c 664)

Así que, después de todo esto es probablemente seguro asumir que:

1. Los mensajes de redirección son parte del funcionamiento normal valgrind.
2. mensaje La advertencia es probablemente el resultado de patrones de especificaciones en conflicto

Referencias (probablemente no es un gran motivo de preocupación en este caso.): Valgrind manual, Valgrind 3.6.1 source