Posibles causas oscuras para Error abstracto en Delphi?

Question

En un proyecto Delphi 7 instalamos FastMM. Poco después notamos que uno de los formularios comenzaba a emitir el mensaje Resumen de error al cerrar. Lo he depurado extensamente y no puedo encontrar el motivo hasta ahora. El motivo habitual de este mensaje de error no parece aplicarse aquí. La aplicación no define clases abstractas. También busqué en el formulario un posible uso de TStrings o algo así. Lo que es más importante, no hicimos (bueno, creemos que no) cambios en este formulario. Simplemente se rompió.

1. ¿Hay alguna otra causa posible para este error además de tratar de llamar al método no implementado?
2. ¿Hay alguna posibilidad de que FastMM haya habilitado algún error oscuro en la aplicación, que permaneció oculto hasta ahora?

Si la respuesta a estas preguntas es no, entonces continuaré buscando una llamada a un método no implementado, aliviada de que no me falta algo más.

Answer 1

Si hay daños en la memoria, se pueden producir todo tipo de errores y es muy difícil encontrar la causa.

Para responder a sus preguntas: 1) Sí, el error abstracto también puede deberse a daños en la memoria, y 2) Sí, habilitar FastMM puede hacer visibles errores que normalmente pasan desapercibidos (pero aún así deben corregirse).

Algunos consejos generales para la búsqueda de errores de memoria:

1. Try "FullDebugMode" puesta en FastMM.
2. Asegúrate de que todo lo que crees tenga un juego gratuito.
3. Asegúrese de que no se libere nada más de una vez.
4. Asegúrate de que un objeto no se use después de que se haya liberado (o antes de que se haya creado).
5. Active las sugerencias y advertencias (y corrígelas cuando se presenten).

Answer 2

"Simplemente se rompió" - probablemente siempre estuvo roto pero ahora lo sabes.

He visto problemas al cerrar un formulario como parte de un evento de botón. El formulario se destruye y el resto de los mensajes del botón se envían a un botón que ya no existe. El método Release evita esto al (desde la memoria) publicar un mensaje wm_close de nuevo en el formulario

Answer 3

Puede intentar agregar u_dzAbstractHandler a su proyecto. Debería generar el error abstracto en el que se llamó al método, por lo que es más fácil depurarlo. Por supuesto, esto solo ayuda cuando ocurre el error cuando se ejecuta en el depurador.

http://sourceforge.net/p/dzlib/code/145/tree/dzlib/trunk/src/u_dzAbstractHandler.pas

Answer 4

respuesta a la pregunta 1:

Sí. Esto es lo que causó en mi caso un error Resumen:

TWinControl(Sender).Visible:= FALSE;   

Esto funcionó cuando el remitente era un TButton pero elevó el error (por supuesto) cuando el remitente era un taction.

Respuesta a la pregunta 2: Sí. He visto que eso también sucede.Deberíamos dejar muy claro que esto no significa que FastMM tenga errores. El error fue 'inactivo'. FastMM solo lo activó.
En realidad, debe confiar en FastMM aún más para encontrar su problema. Cambie FastMM al modo de depuración completa para esto. Se le ayudará con:

Make sure an object is not used after it has been freed (or before it has been created)

Además, en algunos casos, todo el proyecto se arrugó y me dio el error abstracta. Nada funcionó hasta que eliminé el archivo DPROJ. Simplemente haga una comparación entre su archivo DPROJ actual y el que está en su espalda y verá cómo el IDE f **** sube el archivo.