EAccessViolation después de cerrar el programa

[Lepe]

Hola,

Antes de nada, aclaro que quiero indicaciones de por donde atacar el problema, no espero una solución directa.

Tengo una aplicación que peta después de cerrarse, sale la típica ventana de windows "El programa dejó de funcionar y tal" y después de cerrarlo, aparece un EAccessViolation con una dirección de memoria fija 0002657C me hace suponer que es algo que se está destruyendo dos veces pero como digo, ocurre en el dpr después del Application.Run, es decir en el "end."

La aplicación es compleja: Delphi 7 Update 2 con FastMM, componentes IBX 7.11, Firebird 2.5, Indy 9.00, 3 ó 4 ActiveX con programación COM

Como todas las ventanas se crean en ejecución, he logrado acotar el problema a abrir la ventana principal del programa (MDI), cerrarla y obtener el pete. Ahí están las unidades de inicialización de IBEvents, Indy (Antifreeze), etc.


He configurado FastMM para que me enseñe las fugas de memoria, aunque he encontrado unas cuantas, no es nada del tipo de error que me da.

Tambien he usado la JCLDebug con el diálogo de Excepción, mostrando la pila de llamadas y tal, pero en ese punto de la aplicación ya no salta. Es más, tengo el "Stop on Delphi Exception" y el depurador de Delphi no se para.

¿Es correcto pensar que está fallando en una claúsula "finalization" y/o destructor de algo?
¿algo más que mirar?
¿alguna forma de abordar estos errores?

Saludos y gracias

[Casimiro Notevi]

Esos casos son de lo peor para encontrarlos :confused:
1- Puedes "desactivar" algún módulo, compilar y probar.
2- Si falla, entonces lo vuelves a activar y desactivas otro, compilas y pruebas.
3- Si no falla, ya sabes en qué módulo falla y si falla GOTO 2

Siento no poder ayudar mucho, pero ya sabes que estas cosas son de "prueba y error" y mucha lupa detectivesca :)

[egostar]

Hola

Yo "comentaría" los métodos (.Free) de todos los componentes, clases y/o formas que tengas creados en tiempo de ejecución y regresando uno a uno hasta encontrar el culpable, y en específico yo comenzaría por todos los TStrings :)

Saludos

[Lepe]

Asias a ambos, es más o menos lo que hago, con FastMM detecto los memory leaks, desactivando módulos (son más de 300 ventanas) veo que pasa sólo con la ventana principal cargada. Ya he revisado todos los eventos de la ventana.

Incluso he revisado el subversion para ver qué han modificado en las últimas versiones, pero ni así, josss.

En fin, seguiremos rascando a ver si me toca el premio.

Saludos

[newtron]

Hola.

¿Has modificado el action del evento close de alguno de los formularios?.

A mi me pasaba algo parecido y lo solventé quitando el action de uno de los formularios.

Saludos

[Lepe]

Al parecer el problema está en el IBEvents, al tiempo de destruirlo. Conste que uso delphi 7 update 2 + IBX 7.11 con Firebird 2.5, por tanto, para mí es lógico que pete de esta forma. Ya lo dijo el creador de interbase, que Firebird funcione con IBX es mera casualidad.

El componente lo crea y destruye el formulario principal. Hasta hace unas semanas funcionaba sin problemas. Ahora de buenas a primeras BOOOM.

Por cierto, me gusta mucho este código :D (puesto que usa Threads y demás, lo veo hasta lógico):

destructor TIBEvents.Destroy;
begin
try
if Registered then
UnRegisterEvents;
except
// silence any exceptions which might be raised
// by UnRegisterEvents during destruction
end;
...
end;