Hi there,
I'm experimenting systematical crashes of the VM complaining about primitive 195 lately.
When calm down of the annoyance (and code recover) I was able to set up a halt previous to the crash in a Seaside application. Using setp by step, I've noticed that one context stored in the model stored in magma was being evaluated but the debugger was unable to show it's code properly. Still, the context seemed to be evaluating. Making little steps into it lead me to a does not understood exception.
Also noticed that one of the temp vars of that context (t1) was in nil instead of the expected object.
To provide a better idea of the scenario supose this:
PersistedObjectModel>>materials materials ifNil:[self initializeMaterials].
PersistedObjectModel>>initializeMaterials ^ materials := self makeMaterials
PersistedObjectModel>>makeMaterials
^Dictionary new at: #m1 put: (Material new costFunction: [:val| val * self moneyUnit]; yourself); at: #m1 put: (Material new costFunction: [:val| val * self moneyUnit]; yourself); yourself
the PersistedObjectModel is stored in the root dictionary under some key.
If I don't put that halt to follow it with the debugger the DNU never signals. It goes directly to the crash. Maybe the Seaside continuations are interfering for this temp var/signaling?
So seemed to me that somehow Magma was having trouble to identify 'self' in the persisted context of the costFunction in those materials and letting that in nil causing a nil DNU #moneyUnit.
So I've tried a workarround for this: don't make use of self in that context. Just use in the context things that can be deducted more independently of *that contextual situation*. So I've made the seaside session to call the persistedObjectModel like:
costFunction:[:val| val * self session moneyUnit]
(I've made all objects, even nil, to be able to answer the current seaside session)
I'm not proud but so far I prevented that ugly situation,
cheers,
Sebastian Sastre PS1: take care when experimenting with this. I had to recover about 5 hours of work when the first crash occurred to me and 1 hour a second time. PS2: You will not experiment a crash if you create all in the image and then try to test in same instance-image. Instead, after the repository creation, quit Squeak and open it again. There you'll have the crash. I imagine that caches are securing things in the repository creator image.