Thanks. Is it possible your image directory was write-protected? The log indicates it was trying to create the default directory but failed. I can't imaging how that could have to do with the project loaded, unless it fiddled with the default directory path.

- Bert -

On Feb 27, 2007, at 12:14 , Hilaire Fernandes wrote:

Bert Freudenberg a écrit :

...

Could you forward the SqueakDebug.log file that was created when the error occurred?

Here it is.

Hilaire Error: a primitive has failed 27 February 2007 10:23:28 am

VM: unix - a SmalltalkImage Image: Squeakland 3.8-05 [latest update: #552]

SecurityManager state: Restricted: true FileAccess: false SocketAccess: true Working Dir /home/hilaire/Documents/CDDP/Animations/2007-03-28/My Squeak Trusted Dir /home/hilaire/Documents/CDDP/Animations/2007-03-28/secure Untrusted Dir /home/hilaire/Documents/CDDP/Animations/2007-03-28/My Squeak

UnixFileDirectory(Object)>>error: Receiver: UnixFileDirectory on '/' Arguments and temporary variables: t1: 'a primitive has failed' Receiver's instance variables: pathName: FilePath('/')

UnixFileDirectory(Object)>>primitiveFailed Receiver: UnixFileDirectory on '/' Arguments and temporary variables:

Receiver's instance variables: pathName: FilePath('/')

UnixFileDirectory(FileDirectory)>>primCreateDirectory: Receiver: UnixFileDirectory on '/' Arguments and temporary variables: t1: '/home' Receiver's instance variables: pathName: FilePath('/')

UnixFileDirectory(FileDirectory)>>createDirectory: Receiver: UnixFileDirectory on '/' Arguments and temporary variables: t1: 'home' Receiver's instance variables: pathName: FilePath('/')

--- The full stack --- UnixFileDirectory(Object)>>error: UnixFileDirectory(Object)>>primitiveFailed UnixFileDirectory(FileDirectory)>>primCreateDirectory: UnixFileDirectory(FileDirectory)>>createDirectory:

---

UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistence FileDirectory class>>startUp FileDirectory class(Behavior)>>startUp: [] in SystemDictionary>>send:toClassesNamedIn:with: {[:t6 | t5 := self at: t6 ifAbsent: []. t5 ifNil: [t4 add: t6] ...]} OrderedCollection>>do: SystemDictionary>>send:toClassesNamedIn:with: SystemDictionary>>processStartUpList: SmalltalkImage>>snapshot:andQuit:embedded: SmalltalkImage>>snapshot:andQuit: SmalltalkImage>>saveSession TheWorldMenu>>doMenuItem:with: [] in MenuItemMorph>>invokeWithEvent: {[(t2 := selector numArgs) = 0 ifTrue: [target perform: selector] ifFalse...]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: MenuItemMorph>>invokeWithEvent: MenuItemMorph>>mouseUp: MenuItemMorph>>handleMouseUp: MouseButtonEvent>>sentTo: MenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuItemMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuMorph(Morph)>>processEvent:using: MenuMorph(Morph)>>processEvent: MenuMorph>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := t1. t4 := t2 handleFocusEvent: (t1...]} [] in PasteUpMorph>>becomeActiveDuring: {[t1 value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: {[:t3 | ActiveHand := t3. t3 processEvents. t2 := t2 or: [t3 isCapturi...]} Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor yield. false] whileFalse. nil]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]} _______________________________________________ Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland

Okay, so you can reproduce this. In the debugger, can you check which directory it's actually trying to ensure exists? And find out why that fails?

- Bert -

On Mar 2, 2007, at 9:55 , Hilaire Fernandes wrote:

No Bert my directory is not write protected, let me explain the operation I conducted:

• working in my squeakland image (a copy of it in another folder than

the default one, and I start it with squeakvm)

• I create and edit my project with this image, I can save the image

just fine

• I load a project from our swiki (with my squeakland configure

with the smalltalk code at http://superswiki.ofset.org:8000/super/16)

• I save the image ==> error. From there whatever I do (remove the

loaded project), I cannot save the image

• I quit squeak and restart it, with the last saved image (before

the bang)

• I reload the downloaded project, but from the local copy now in 'My

Squeak, This time I can save the image just fine.

Hope it helps,

Hilaire

Bert Freudenberg a écrit :

...

Thanks. Is it possible your image directory was write-protected? The log indicates it was trying to create the default directory but failed. I can't imaging how that could have to do with the project loaded, unless it fiddled with the default directory path.

---

Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland

No, what I mean is, what directory was it trying to create originally. You have to look in the debugger stack where the first assureExistence is called to see that directory.

- Bert -

On Mar 2, 2007, at 12:41 , Hilaire Fernandes wrote:

Sure, it is trying to create the /home directory, odd don't you? At first I was wondering if I was analysing correcty.

I load a .pr which does not produce this problem. Form superwiki ofset.org:8000

• the pb arised with 'v-toys voiture sur route-7.pr'
• the does not arise with 'modele de diapo inter-2'

Both project are at top of the list.

Does it produce the same pb for you?

Hilaire

Bert Freudenberg a écrit :

...

Okay, so you can reproduce this. In the debugger, can you check which directory it's actually trying to ensure exists? And find out why that fails?

Recheck again at home and I can reproduce the same problem.

Load from swiki a project then save image under a different name, so:

Smalltlalk>>saveImageinFileName:t1 t1='/home/hilaire/.npsqueak/My Squeak/SqueakPlugin.1.image'

Then the recursive call of 'assureExistenceOfPath: t1' go up to home, then the call primCreateDirectory t1 with t1='/home' It is then primitive land, which I don't know

I will look at the OLPC version.

Hilaire

Hilaire Fernandes a écrit :

Bert Freudenberg a écrit :

...

No, what I mean is, what directory was it trying to create originally. You have to look in the debugger stack where the first assureExistence is called to see that directory.

Strangely it was not clear as I did not see any absolute pathname, only successive directory. However it was looking like it starts down from 'My Squeak' folder. I will give it a serious check later next week as I was in hurry recently.

Hilaire

...

• Bert -

On Mar 2, 2007, at 12:41 , Hilaire Fernandes wrote:

...

Sure, it is trying to create the /home directory, odd don't you? At first I was wondering if I was analysing correcty.

I load a .pr which does not produce this problem. Form superwiki ofset.org:8000

• the pb arised with 'v-toys voiture sur route-7.pr'
• the does not arise with 'modele de diapo inter-2'

Both project are at top of the list.

Does it produce the same pb for you?

Hilaire

Bert Freudenberg a écrit :

...

Okay, so you can reproduce this. In the debugger, can you check which directory it's actually trying to ensure exists? And find out why that fails?

Bert Freudenberg wrote:

The debug log you attached before shows that your image was in restricted mode. In this sandbox mode, you are only allowed to write inside the SecurityManager's "untrusted directory". I don't think you're even supposed to save the image when in sandbox mode, so if you try anyway, there might be any number of bugs lurking. IIRC the image save logic assumes that FileDirectory default and the image directory are identical. But in sandbox mode, this is not true anymore.

That is correct. With the sandbox on, you can't safe the image - otherwise this would be a trivial way for a malicious bit of code to make itself forever at home in that image.

Cheers, - Andreas

Bert Freudenberg wrote:

On Mar 3, 2007, at 8:11 , Andreas Raab wrote:

...

That is correct. With the sandbox on, you can't safe the image - otherwise this would be a trivial way for a malicious bit of code to make itself forever at home in that image.

Well, you should be able to save the image in the untrusted directory, right? Squeakland users usually never save the image, and Squeak.org users never enable the sandbox, so there might well be bugs hidden there.

No, it is intentional that you cannot save the image even in the untrusted directory. It avoids the impression that there is a bug in the sandbox (not being able to save the image anywhere) that people "work around" by saving the image in the untrusted directory and running it from there (which would completely defeat the purpose of all of the mechanisms in place). If you want to live risky (i.e., save the image with unknown code in it that will forever be part of that image) then you have to be explicit and turn off the sandbox entirely.

Cheers, - Andreas

Hilaire Fernandes a écrit :

I will look at the OLPC version.

With etoy-dev-2 and update, the problem does not show up.

Hilaire Fernandes a écrit :

Hilaire Fernandes a écrit :

...

I will look at the OLPC version.

With etoy-dev-2 and update, the problem does not show up.

So may be there is a security risk there. Well, in my scenario, there is an explicit superswiki registered in the image, may be it can not be the case for the olpc version.

Hilaire