Opened 14 years ago
Closed 13 years ago
#1132 closed defect (fixed)
Cyclic references in BysMcmc causes undecompilable objects
Reported by: | Pedro Gea | Owned by: | Víctor de Buen Remiro |
---|---|---|---|
Priority: | normal | Milestone: | Mantainance |
Component: | BSR | Version: | head |
Severity: | critical | Keywords: | |
Cc: |
Description
Se han encontrado objetos de BysMcmc que no pueden decompilarse o destruirse debido a las referencias cíclicas o mutuas entre ellos.
Este hecho se aprecia al utilizar bloques no lineales.
Se adjunta un ejemplo en el que se detecta este hecho en el incremento de NObject
(descomprimir y ejecutar test.tol).
Attachments (1)
Change History (7)
Changed 14 years ago by
comment:1 Changed 14 years ago by
comment:2 Changed 14 years ago by
Para los propósitos de MMS de mantener un control de los objetos creados, basta con destruir estos objetos entrerrelacionados después de utilizarlos.
Para ello se encuentra que el código:
Set EvalSet(cycler::_.sampler::_.nonLinBlk, Real (NameBlock nlb) { NameBlock nlf = nlb::_.filter; NameBlock nlf := [[ Real null = True ]]; NameBlock nlb := [[ Real null = True ]]; 1});
es suficiente para deshacer el problema.
Supongo que no es fácil de evitar sin modificar algo el diseño de las clases, quizá en una futura revisión podría tenerse en cuenta el riesgo de este tipo de relaciones.
comment:3 Changed 14 years ago by
Status: | new → accepted |
---|
A mí no se me ocurre por el momento ninguna forma eficiente, ya no de evitar, sino simplemente de detectar referencias cíclicas. Cada objeto debería conocer todos los objetos que le referencian y aquellos a los que referencia y explorar todos los caminos posibles recursivamente para constatar si alguno de ellos es cíclico. Los ciclos no tiene porqué darse en el primer nivel: A puede referenciar a B que referencia a C que a su vez referencia a A.
Lo que sí que habrá que revisar es el código de BysMcmc para evitar ese caso concreto.
comment:4 Changed 14 years ago by
Según mis cálculos debería bastar con hacer
Set cycler::_.sampler::_.nonLinBlk := Copy(Empty);
¿Podrías comprobarlo?
comment:5 Changed 14 years ago by
Lo he probado, pero eso sólo no basta.
Si no me equivoco hay un doble ciclo de referencias: el sampler contiene bloques (nlb) y éstos filtros (nlf) ambos contienen referencias al sampler, pero también referencias entre sí. Al vaciar el conjunto de bloques éstos se decompilarían si nadie los apuntara, pero los filtros (que ellos mismos contienen) los apuntan.
comment:6 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Se sospecha que el problema es algo similar al descrito en #836 y ocurre entre los objetos
_this, nlf y nlb
que aparecen en un métododefine.all
de la clase @BsrMaster. Véase _bsrMaster.tol línea 177 y siguientes