close Warning: Can't synchronize with repository "(default)" (/var/svn/tolp does not appear to be a Subversion repository.). Look in the Trac log for more information.

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1416 closed defect (fixed)

Bug in GetAddressFromObject

Reported by: Jorge Owned by: Víctor de Buen Remiro
Priority: highest Milestone: Mantainance
Component: Kernel Version: head
Severity: blocker Keywords:
Cc: Javier Gallardo

Description (last modified by Jorge)

In the following code you can see that GetObjectFromAddress does not work

Set X = [[ For(1, 10, Set(Real k){ [[k]] } ) ]];
Text tad = GetAddressFromObject( X[1] );
Set obj = GetObjectFromAddress( tad );

but if the result of the For sentence has a name then it works as expected.

This bug is related to #1415.

Change History (7)

comment:1 Changed 13 years ago by Jorge

Description: modified (diff)

comment:2 Changed 13 years ago by Víctor de Buen Remiro

Ya tengo localizado el problema, o mejor dicho los problemas. Todo está relacionado con el sistema de manejo de memoria BFSMEM. Se trata de un gestor de RAM ad-hoc que afecta a la mayor parte de los objetos de TOL, que además de servir de caché inteligente y acelerar el manejo de la memoria dinámica, es capaz de distinguir, en determinadas circunstancias, si un objeto sigue vivo todavía o ha sido borrado. No se trata de un sistema infalible, en el sentido de que no evita al 100% el problema del acceso inválido de memoria, pero se ha visto heurísticamente que funciona bastante bien, y desde luego es mucho más informativo que el gestor proporcionado por el sistema operativo que simplemente no dice nada al respecto.

La función GetObjectFromAddress hace uso de esa capacidad para evitar accesos de memoria inválida si el objeto es borrado después de la llamada a GetAddressFromObject, o bien si se le pasa una dirección inválida por el motivo que sea. En tal caso GetObjectFromAddress no devuelve ningún objeto sino el puntero NULL por lo que no es posible asignarlo al objeto Set obj

Sin embargo, en el caso del ejemplo, el objeto X[1] está claramente vivo por lo que no debería devolverse NULL.

Lo que ocurre es que, por diferentes motivos que sería largo detallar, no todos los objetos C++ usados internamente en TOL son susceptibles de ser manejados por BFSMEM

Por una parte la clase BTmpContens<Any> de los objetos temporales tenía deshabilitado el BFSMEM, lo cual incluye el caso de nuestro X[1] cuando no tiene nombre asignado, pues en tal caso pasa a ser un BRenContens<Any> y desaparece el problema aparentemente. Hay otros subtipos de objetos que no tienen nombre que no vienen de BTmpContens<Any> y por eso tampoco daban problemas a simple vista.

Por otra parte ni siquiera eso debería ser problema, pues de los objetos no manejados por BFSMEM, ante la pregunta de si están vivos, mediante el método IsAssigned deberían devolver -1, interpretable como que no es posible conocer si está vivo o no, y en cuyo caso GetObjectFromAddress lo da por bueno y que pase lo que tenga que pasar.

El hecho es que al tratarse de una clase no manejada por BFSMEM pero que desciende de otra clase que sí lo es, debería sobrecargarse el método IsAssigned y no se hacía.

Por último, creo que es necesario que antes de llamar a GetObjectFromAddress sería necesario asegurarse, en la medida de lo posible, de que realmente la dirección es correcta y corresponde a un objeto vivo, para lo cual sería necesario crear la función

  Real AddressIsAlive(Text address)

Especialmente debería utilizarse cuando se le llama desde el interfaz y no es posible asegurarse con certeza de que el objeto cuya dirección quedó apuntada por GetAddressFromObject no ha sido borrado mientras tanto.

comment:3 Changed 13 years ago by Víctor de Buen Remiro

(In [4063]) Refs #1416
Refs #1415

comment:4 Changed 13 years ago by Víctor de Buen Remiro

(In [4064]) Refs #1416
Refs #1415

comment:5 Changed 13 years ago by Víctor de Buen Remiro

(In [4065]) Refs #1416
Refs #1415

comment:6 Changed 13 years ago by Víctor de Buen Remiro

Resolution: fixed
Status: newclosed

En principio el problema ha sido resuelto ya en el trunk, aunque debido a la profundidad de los cambios introducidos es necesario hacer un chequeo exhaustivo antes de subir la versión binaria de desarrollo.

comment:7 Changed 13 years ago by Víctor de Buen Remiro

(In [4077]) Refs #1416

Note: See TracTickets for help on using tickets.