2012-04-03 11 views
5

Así que recientemente comencé a trabajar en un gran proyecto de software que enlaza en varias bibliotecas estáticas y dinámicas en OSX, utilizando el compilador llvm-gcc.Inspeccionando bibliotecas C++ para diferentes enlaces stl para rastrear std :: destructor vector crash en gcc/osx?

Tengo serios problemas con el stl. Específicamente, el código muy simple se bloqueará. Por ejemplo, en mi proyecto principal, el siguiente código se colgará:

{ 
    std::vector< unsigned int > testvec; 
    testvec.resize(1); 
    testvec[0] = 0; 
} 

que se colgará cuando se sale del alcance, en el interior de la std :: vector < unsigned int> destructor, lanzando una SIGABRT y diciendo que la memoria ser desasignado no ha sido asignado. Específicamente:

malloc: *** error for object 0x135e8fc30: pointer being freed was not allocated 
*** set a breakpoint in malloc_error_break to debug 

Esto solo ocurre en una compilación de lanzamiento: la compilación de depuración funciona bien.

Mi mejor versión es que una de las bibliotecas externas está vinculada a otra versión de la STL que utiliza un diseño de memoria interna diferente, por lo que está tratando de desasignar el tamaño o algo así.

He corrido nm en todas las bibliotecas con las que estoy enlazando, y varias de ellas tienen símbolos stl externos (específicamente, std :: vector < unsigned int> destructor está marcado con una S en la salida nm) . Pero no puedo descifrar cuál es el culpable.

¿Hay alguna manera de inspeccionar los archivos .a o dylib para rastrear cuáles están vinculados con una versión diferente del STL?

[editar]

Esto se ve como un ejemplo del mundo real de la situación descrita en Two static libs, two different vector implementations, what would the linker do? Resulta que el enlazador hace horribles, horribles cosas .. :)

+1

¿Qué sucede si pasa por la instrucción de la máquina a través de la llamada al destructor? ¿Qué biblioteca terminas adentro? –

+0

@ZanLynx gracias, terminé entrando en el operador nuevo en un proyecto pequeño que se vinculaba con diferentes bibliotecas, y finalmente lo reduje al que devolvía un valor diferente al del constructor. – tfinniga

Respuesta

2

creo que es lo que otool -L 'que estas buscando. Esto mostrará una lista de las bibliotecas compartidas que usa el programa.

También debe verificar su ruta de inclusión. Parece poco probable, pero es posible que #include <vector> esté extrayendo una inclusión no estándar, cuya definición no coincide con lo que está en la biblioteca estándar.

Cuestiones relacionadas