#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 )
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
Description: | modified (diff) |
---|
comment:2 Changed 13 years ago by
comment:6 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
Note: See
TracTickets for help on using
tickets.
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 aGetAddressFromObject
, o bien si se le pasa una dirección inválida por el motivo que sea. En tal casoGetObjectFromAddress
no devuelve ningún objeto sino el punteroNULL
por lo que no es posible asignarlo al objetoSet obj
Sin embargo, en el caso del ejemplo, el objeto
X[1]
está claramente vivo por lo que no debería devolverseNULL
.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 nuestroX[1]
cuando no tiene nombre asignado, pues en tal caso pasa a ser unBRenContens<Any>
y desaparece el problema aparentemente. Hay otros subtipos de objetos que no tienen nombre que no vienen deBTmpContens<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 casoGetObjectFromAddress
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ónEspecialmente 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.