Hi all,
looking for a new way to crash the image? :-) Here is one:
gen := Generator on: [:gen |
self assert: gen next isNil.
self error].
gen yield: 1.
This is a less idiomatic but more comprehensible version:
[c := thisContext.
[h := thisContext.
[h swapSender: thisContext sender.
c := thisContext swapSender: c] value.
thisContext swapSender: c] value] value.
[c := thisContext swapSender: c.
self error] value.
In a nutshell, the Generator temporarily creates a loop on the stack while switching coroutines. I didn't fully get behind its implementation at the moment, and I acknowledge that I am using the generator in the "wrong" way - usually the #on: block is the producer not the consumer. However, and especially with the recent debate on safe languages in mind, I wonder whether we would be able and willing to make Squeak safe against this phenomen (loops on the stack).
The actual crash (or better: hang) comes from primitiveFindHandlerContext, but I assume primitiveFindNextUnwindContext and primitiveTerminateTo would cause a similar effect. A simple fix would be to disable these optional primitives and use the image fallback instead. This makes the method interruptable similar to a convenient infinite loop. However, this is obviously much slower. I wonder whether these primitives could be made aware of possible context stack loops and fail when a loop is detected. When the primitive fails, the fallback code would run so the image would be interruptable again, or even better, we could also detect particular stack loops then:
Context>>findNextHandlerContextStarting
"Return the next handler marked context, returning nil if there is none. Search starts with self and proceeds up to nil."
- | ctx |
- <primitive: 197>
+ | ctx known |
ctx := self.
+ known := IdentitySet new.
[ctx isHandlerContext ifTrue:[^ctx].
+ (known ifAbsentAdd: ctx) ifFalse: [Processor debugWithTitle: 'Loop on stack detected!' translated full: false].
(ctx := ctx sender) == nil ] whileFalse.
^nil
So my questions to you are: Do we want to support this kind of safety (I would like it!)? Is this possible to implement in the VM without a concerning performance impact?
Best,
Christoph
---
Sent from Squeak Inbox Talk