"este" puntero se corrompe en el seguimiento de la pila

Question

He visto this hilo. Mi caso es un poco diferente y estoy luchando para descubrir cómo el puntero "this" se corrompe.

Estoy usando el framework Qt 4.6.2, usando su QTreeView con mi propio modelo. La traza inversa que obtengo (86 fotogramas de largo, con mucha recursividad, es por eso que no he pegado todo, es en este pastebin solo implica su código.

Finalmente segfaults en algún ensamblador en QBasicAtomicInt :: DEREF, pero es obvio que ha muerto más abajo, evidenciado por estos tres cuadros:.

#15 0x01420fd3 in QFrame::event (this=0x942bba0, e=0xbf8eb624) at widgets/qframe.cpp:557 
#16 0x014bb382 in QAbstractScrollArea::viewportEvent (this=0x4, e=0x93f9240) at widgets/qabstractscrollarea.cpp:1036 
#17 0x0156fbd7 in QAbstractItemView::viewportEvent (this=0x942bba0, event=0xbf8eb624) at itemviews/qabstractitemview.cpp:1610 

en marco 17, this es 0x942bb0 en marco 16, this debe ser el mismo, como en el bastidor 17 que está llamando a su Implementación de un antepasado del mismo método. Sin embargo, this se convierte en 0x4.

Curiosamente en el cuadro 15 (de nuevo, el cuadro 16 ha llamado a su antecesor la implementación de la misma función), el puntero 'this' se restaura a 0x942bba0.

Si miraba el pegado de la traza trasera completa, es posible que vea un "valor optimizado fuera". Hice que la aplicación compilara con optimización; Ahora tengo gcc configurado en -g3 -O0 así que cuando suceda la próxima vez podría tener algo más. Pero, por supuesto, ahora no puedo hacer que se cuelgue; es un error bastante difícil de realizar (pero, no obstante, es muy importante solucionarlo), así que no creo que sea demasiado sospechoso.

Teniendo en cuenta las optimizaciones, ¿thispointer=0x4 es inusual o definitivamente incorrecto? Lo que es extraño es que no hay un código real en ninguno de estos marcos de evento viewport; simplemente hacen un cambio en el tipo de evento, cae a través de la instrucción switch y devuelve la implementación de su antecesor.

Valgrind no parece estar planteando ningún problema, aunque todavía no lo he hecho colapsar en Valgrind.

¿Alguien ha visto este comportamiento antes? ¿Qué podría estar causando eso?

Answer 1

He visto este tipo de cosas antes al depurar compilaciones optimizadas y nunca ha sido una indicación de cuál es el verdadero error para mí.

Es más fácil pensar primero en una variable local. En una compilación no optimizada, todo tiene su lugar designado en la memoria y debe almacenarse después de cada línea de código. Esto es para que el depurador pueda encontrarlo. En una compilación optimizada, los valores pueden vivir en registros sin estar escritos en la memoria. Esta es una parte importante del rendimiento mejorado de una construcción optimizada. El depurador no entiende esto y siempre observará la memoria, por lo que a menudo verá el valor incorrecto.

Lo mismo puede pasar con los parámetros. Si el optimizador decide pasar un parámetro en un registro, el depurador seguirá mirando el marco de la pila. Más específicamente, en la ubicación donde el parámetro estaría de acuerdo con las reglas de la convención de llamadas.

El hecho de que el siguiente fotograma de la pila tenga el valor restaurado correctamente indica que las instrucciones generadas tratan este parámetro correctamente, pero el depurador simplemente no sabe dónde buscarlo.