Un error que ni EurecaLog detecta!!!

[noshy]

Empezado por Al González

Veo que es una aplicación de 64 bits (16 dígitos hexadecimales para las direcciones de memoria). ¿Te es posible compilar y ejecutar la aplicación en 32 bits? ¿Ocurrirá el mismo problema como aplicación de 32 bits?

Por otro lado, un AV con dirección de memoria muy baja es sintomático de intentar usar un objeto Nil; en el desplazamiento 2C8 de la instancia del objeto estaría el campo al que se desea acceder. Si es así, ese desplazamiento pareciera el de un objeto cuya clase posee cierto número de propiedades (particulares más heredadas). Digamos que objeto pequeño no es.


¿Es posible que al momento de capturar esa imagen haya habido alrededor de 30 hilos activos? (Uno por cada ventana de error). Es casi seguro que esas ventanas de error en cascada surgen de algo que se está ejecutando en segundo plano. ¿Cuál es el código que programaste para esos hilos? Y ¿hay otros hilos para otras tareas?

Saludos.

Al González.

Hola, si es una app de 64 bits, si lo compilo en 32 me pasa lo mismo no hay mejora.

Con respecto a que es un obejto = nil, yo pense lo mismo,pero seguramente no es un objeto que yo creo en el código, ya que si fuera asi me lo tomaria alguna exception, y no lo toma inclusive me lo deberia tomar eurekalog, o me daria error en algunos hilos y no en todos.

Para que te des idea del porque la cantidad de dialogos de error, la app funciona perfectamente hasta que en un momento todos los hilos comienzan a generar el mismo error, es como que en cada paquete que recibe se genera el error, que es lo que me llama la atencion ya que si fuera un objeto mal cerrado o algun paquete recibido con error no pasaria en todas las conexiones, o sea que lo que ves que son 30 dialogos con error en realidad son muchos mas porque sobre el margen inferior derecho estan superpuestos y es imposibles cerrarlos a mano ya que tengo un aproximado de 7 conexiones por segundo, imaginate la cantidad de errores que larga en ese momento.

Editado: Elcodigo del thread es el que publique arriba, lo publique en dos partes porque no entraba todo en un solo mensaje, ese es el procedimiento del evento OnExecute delcomponente Indy TCPServer.
La primer parte son las funciones declaradas dentro del pocedimiento para que las cargue en cada thread y la segunda parte esel procedimiento en si.