Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > OOP
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Grupo de Teaming del ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 14-11-2013
Avatar de rcarrillom
[rcarrillom] rcarrillom is offline
Miembro Premium
 
Registrado: dic 2004
Ubicación: UK / North Sea / Norway / Golfo de México / Frente a mi Laptop
Posts: 219
Poder: 20
rcarrillom Va por buen camino
Existe alguna directiva para inicializar variables tipo objeto a Nil?

Un saludo al foro.

Estoy dando mantenimiento y portando código de 32 a 64 bits (D7 a XE3) que supera los dos millones de lineas de código, se complica el asunto de depuración porque un ejecutable hace llamadas a varios DLLs COM al mismo tiempo y son cajas negras, o depuro el EXE o depuro el DLL; tengo el código de todos ellos. Entre los detalles que me han surgido hay uno que da dolores de cabeza y espero que se pueda resolver de manera rápida para no urgar las dos millones de lineas:
  • Como procedimiento de programacion típico de los otros programadores anteriores se declaran variables locales tipo TDataSet dentro de los DLLs que al final del Método se destruyen con FreeAndNil, pero no siempre se crean las instancias, por ejemplo si se cumple un IF se llama al TDataSet.Create(), si no se cumple, la variable no se utiliza nunca.
  • Al terminar el procedimiento se intenta liberar todas las variables con FreeAndNil, hayan sido o no instanciadas.
  • Si no ha sido instanciada, la variable tiene una referencia inválida ya que nunca se le asignó Nil al iniciar (el programador anterior asumió que se inicializaban las variables de manera predeterminada ) y el FreeAndNil falla estrepitosamente con un Access violation read of address ... (con las versiones de 32 bits de los DLLs no ocurre, con las de 64 bits, sí), el mensaje casi nunca dice que address sea 0 o puras FFFs lo que sería indicativo de que es algo no asignado, por lo que nos fuimos a depurar los procesos y tardamos 4 dias la primera vez en localizar la fuente del error... dentro del bloque except end , el principal.
He leido que se inicializan a cero, vacio, nil o lo que aplique las variables de objetos (fields), variables globales, pero no las variables locales.

Pues bien, la solucion fué asignar Nil a todas las variables antes de utilizarlas, pero por la cantidad de código y métodos que tienen el mismo defecto es una tarea titánica y por los calendarios asignados no nos dan tiempo para esta tarea, por lo cual mi duda es saber si existe una directiva de compilación que haga que se inicialicen a Nil de manera automática los punteros y variables de objeto.

Gracias
__________________
eLcHiCoTeMiDo - Rompecorazones profesional
Yo no soy presumido; ¿Pero de qué sirve mi humilde opinión contra la de los espejos?
Salva a un nylon, usa prendas de piel de foca
Responder Con Cita
  #2  
Antiguo 16-11-2013
Avatar de rcarrillom
[rcarrillom] rcarrillom is offline
Miembro Premium
 
Registrado: dic 2004
Ubicación: UK / North Sea / Norway / Golfo de México / Frente a mi Laptop
Posts: 219
Poder: 20
rcarrillom Va por buen camino
[Resuelto]

Saludos al foro

Hemos encontrado el problema de las excepciones y comparto la solución para quien pueda servirle.

El proyecto originalmente consta de un lado cliente EXE y un lado servidor DLL DCOM, originalmente todo bajo D7 a 32 bits. Cuando se hizo la portación del código servidor de D7 a XE3 para 32/64 bits, empezaron a surgir errores extraños que detectamos eran fallas de FreeAndNil por objetos no inicializados dentro de los DLL compiladas con XE3 para 64 bits, extrañamente el mismo código compilado con XE3 para 32 bits no marcaba excepciones. Hicimos pruebas con código casi identico al del proyecto combinando SO de 32/64 bits con EXE 32 bits y DLLs 32/64 bits y la unica combinacion que no marcaba error fue DLL creados con D7 corriendo en Win 64, contrario a la documentacion de Borland/Embarcadero que dice que las variablesl locales no se inicializan y de entrada traen basura, en los watch aparecian inicializadas a nil dentro del DLL, esta extraña condicion siempre estuvo presente y por esta razon no habia excepciones. Este fue el primer detalle curioso.

Después de una maratónica sesión de google y de una lista de posibles causas, la última razón y que nadie creyó posible, fué investigar la convencion de llamada safecall (usada casi exclusivamente en interfaces DCOM) ya que en la declaracion de los eventos y métodos que generamos en las pruebas no aparece, siendo la convencion predeterminada register si no me equivoco, resulta que la particularidad que tiene safecall es establecer un "firewall" para las excepciones entre el invocador y el método invocado, aunque existan errores en el DLL no llegan al cliente y como la liberacion estaba en un bloque try finally end, se hacia todo el proceso al 100% y desaparecia la excepcion por arte de magia, ya que se debe preguntar a traves de una interfaz al objeto DCOM; al parecer siempre hubo errores pero nunca salieron a la luz.

Sumado a esto, la documentación técnica dice que para X64 ya solo existe un solo tipo de llamada y dejan de existir los fastcall, register, cdecl, safecall, etc. y obviamente esto hizo desaparecer la barrera para las excepciones y fué la receta perfecta para el desastre.

En resumen, safecall ocultaba las excepciones en 32 bits y en 64 bits solo existe un tipo de llamada y se manifestaron los errores.

Ahora solo queda buscar esas lineas propensas a fallos a ojo pelón adiós dia lunes no laborable...
__________________
eLcHiCoTeMiDo - Rompecorazones profesional
Yo no soy presumido; ¿Pero de qué sirve mi humilde opinión contra la de los espejos?
Salva a un nylon, usa prendas de piel de foca
Responder Con Cita
  #3  
Antiguo 16-11-2013
Avatar de pacopenin
pacopenin pacopenin is offline
Miembro
 
Registrado: sep 2010
Ubicación: Asturias
Posts: 382
Poder: 14
pacopenin Va por buen camino
Gracias por ir compartiendo tus descubrimientos. Imagino que aún está poca gente convirtiendo de 32 a 64, así que todas las luces que se vayan aportando será camino ganado cuando nos toque al resto. Un saludo.
__________________
http://www.gestionportable.com
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
¿Existe alguna función para saber si una cadena tiene un formato determinado? Kandorf OOP 4 16-08-2010 05:43:55
Existe alguna tecnica para no repetir codigo? pablopessoa Varios 25 11-03-2010 01:28:41
existe alguna utilidad o manual para migrar codigo a Delphi 2009? cocute Varios 5 05-02-2009 12:16:17
Existe alguna clase para serializar un objeto en Delphi rgstuamigo OOP 4 04-10-2008 15:05:20
Crear variables de tipo Objeto!! rodrigo19 Varios 2 26-05-2007 03:40:14


La franja horaria es GMT +2. Ahora son las 21:03:03.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi