[BUG][VM] long Delay schedules a deferred image crash
David T. Lewis
lewis at mail.msen.com
Sun Jan 30 20:19:38 UTC 2005
Here's a tasty little bug. If you schedule a Delay with a duration long
enough to be a LargeInteger, it will sit happily in the SuspendedDelays
queue until such time as it becomes the next Delay to be activated. At that
time, #primitiveSignalAtMilliseconds is called. The primitive is only able
to handle SmallIntegers, so it fails, whereupon #primSignal:atMilliseconds:
attempts to throw 'a primitive has failed', which bolluxes up the works
in the process scheduler. As far as I can tell, this is an unrecoverable
error condition.
The following illustrates the problem and will usually crash your image:
| bigDelay |
bigDelay := Delay forSeconds: SmallInteger maxVal + 1.
[bigDelay wait.
Transcript show: 'I have been waiting a long time for this'; cr] fork.
(Delay forSeconds: 1) wait.
Smalltalk garbageCollect "=> image will hang after failed primitive"
Two things need to be addressed:
1) The primitive should accept large integer arguments. Note that the
longest possible delay with a small integer is only about 12 days:
Duration seconds: (SmallInteger maxVal / 1000) asInteger => 12:10:15:41
2) Delay class>>primSignal:atMilliseconds: should do something other than
#primitiveFailed when the primitive fails. Perhaps writing something to the
Transcript would make sense, or just ignore the failure entirely?
This is #854 on Mantis.
Dave
More information about the Squeak-dev
mailing list
|