Core dump report

[Lee Salzman]

You are using ensure wrong.

x ensure: y immediately executes x. Once x is finished executing, y
executes. In the event x exits prematurely, y is executed before
unwinding the stack. y does NOT take any arguments.

Lee

On Wed, Aug 04, 2004 at 03:40:26PM +0200, Lendvai Attila wrote:
> 
> I've forgotten the code that triggers it:
> 
> fileName1@(File Locator traits) compareContentsTo: fileName2@(File
> Locator traits)
> [
>   (File newNamed: fileName1 &mode: File Read) sessionDo:
>     ([| :file1 |
>       (File newNamed: fileName2 &mode: File Read) sessionDo:
>         [| :file2 |
> 	   t copmareFileContents: file1 with: file2
>         ]
>     ] on: Stream Exhaustion do: [| :c | ^ False]).
> ].
> 
> 
> take a look at the () around a [] with an ensure: call. I assumed that
> ([] ensure: [| :c | ]) returns a block with an ensure attached and used
> it for sessionDo: ... after looking at the interpreter code it may be
> illegal.
> 
> so what is the official answer, is it a bug / an illegal code / not yet
> supported feature?
> 
> - 101
> 
> :: hi!
> :: 
> :: in prims.slate:
> :: 
> :: body at CompiledMethodTraits ensure: unwindBlock at CompiledMethodTraits [
> ::   interpreter
> ::     apply: body pointer!(CompiledMethod pointer) cast
> ::     to: Nil
> ::     arity: 0
> ::     withOptionals: Nil.
> ::   interpreter lexicalContext unwindBlock: unwindBlock
> :: ] `pidginPrimitive. 
> :: 
> :: 
> :: in vm.slate:
> :: 
> :: i@(Interpreter pointer) apply: method to: args arity: n 
> :: withOptionals: opts [| method!(CompiledMethod pointer) 
> :: args!(ObjectPointer pointer) opts!(OopArray pointer) 
> :: lexicalContext!(LexicalContext pointer) inputs |
> ::    lexicalContext: (CurrentMemory newOopArray: LexicalContextProto
> :: sized: method localVariables asSmallInt)!(LexicalContext 
> :: pointer) cast.
> ::    inputs: method inputVariables asSmallInt.
> ::    args!(Word pointer) cast
> ::      copyWords: inputs
> ::      into: lexicalContext variables!(Word pointer) cast.
> :: ...
> :: 
> :: So the upper one calls the lower one, with to: Nil (probably 
> :: instead of ObjectHeap NilObject) and it causes the apply 
> :: method to access 0x00000000 as the value of Nil is 0.
> :: 
> :: I don't know exactly what's happening there, so I leave it 
> :: for Lee... :) Could be that apply and friends should be 
> :: prepared for Nil...
> :: 
> :: Make sure to look around in there (prims.slate), because 
> :: there are quite a few Nil's used all around. Could be other 
> :: problems, too. (If it is a problem at all, as opposed to me 
> :: screwing up something)
> :: 
> :: Happy coding,
> :: 
> :: - 101
> :: 
> :: 
> :: 
>