DNU in persisted contexts and VM crashes

[Sebastian Sastre]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash.dmp
Type: application/octet-stream
Size: 1129 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/magma/attachments/20071124/bad90b9c/crash.obj