Posted by Dale Henrichs-3 on Jul 28, 2016; 8:47pm
URL: https://forum.world.st/newly-introduced-problem-in-Pharo5-0-running-headless-vm-Ubuntu-14-04-tp4908532p4908544.html

Thanks Nicolai ... that looks exactly like my problem ... I see that this report is from earlier in July, so it presumably will crop up randomly ..

Dale

Hi Dale,

I think this problem already exists in Pharo 5.0, see bug report
18706 Build of Pharo5 is broken

2016-07-28 22:58 GMT+02:00 Dale Henrichs <[hidden email]>:

Three additional pieces of info ...

1. 'canvas' is an instance variable in the WorldState instance and is probably a stale instance along with a stale process
2. If I bring up the image headful, I get no errors and then if I save it, the load works properly ...
3. If I run the load on Pharo.image directly without the initial ` ./pharo Pharo.image save xxx`, it loads properly

This sequence is in a script that I ship to end users, so if `./pharo Pharo.image save xxx` is intended to work, I will wait patiently for a bugfix (and submit a bug if necessary -- I originally thought that this might have been recently introduced, but now I think that this is a bug that is possibly just recently exposed) otherwise, I'll have to rewrite the scripts to not rely on `./pharo Pharo.image save xxx`.

Dale

On 07/28/2016 01:49 PM, Dale Henrichs wrote:

This sequence of commands was working yesterday and is broken today:

  ./pharo Pharo.image save xxx; ./pharo xxx.image --quit --save ./boom.st

The contents of boom.st is the following:

    Metacello new
          baseline: 'Metacello';
          repository: 'github://dalehenrich/metacello-work:master/repository';
          onConflict: [:ex | ex allow];
      load: #( 'batch' ).

I've attached to PharoDebug.log ... The Pharo.image is freshly downloaded along with the vm. Needless to say, the expression above works when run with a GUI. Oddly enough the receiver of #finish looks to be a temp named 'canvas' in the middle of the WorkState>>displayWorld:submorphs: method ... two lines earlier the' canvas' temp had to have a valid value, so this has the look of a zombie process of some sort that is being brought to life at the wrong moment ...

stdout for the run follows.

Dale

foos:voyage>./pharo Pharo.image save xxx; ./pharo xxx.image --quit --save ./boom.st
Error: MessageNotUnderstood: receiver of "finish" is nil
UndefinedObject(Object)>>error:
[ :err :rcvr |
| errCtx errMorph |
errCtx := thisContext.
[ errCtx := errCtx sender.
"Search the sender chain to find the morph causing the problem"
[ errCtx notNil and: [ errCtx receiver isMorph not ] ]
    whileTrue: [ errCtx := errCtx sender ].
"If we're at the root of the context chain then we have a fatal drawing problem"
errCtx ifNil: [ ^ self handleFatalDrawingError: err ].
errMorph := errCtx receiver.
"If the morph causing the problem has already the #drawError flag set,
            then search for the next morph above in the caller chain."
errMorph hasProperty: #errorOnDraw ] whileTrue.
errMorph setProperty: #errorOnDraw toValue: true.
"Install the old error handler, so we can re-raise the error"
rcvr error: err ] in WorldState>>displayWorldSafely: in Block: [ :err :rcvr | ...
BlockClosure>>cull:cull:
[ :ex | errorHandlerBlock cull: ex description cull: ex receiver ] in BlockClosure>>ifError: in Block: [ :ex | errorHandlerBlock cull: ex description cul...etc...
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
MessageNotUnderstood(Exception)>>signal
UndefinedObject(Object)>>doesNotUnderstand: #finish
WorldState>>displayWorld:submorphs:
WorldMorph>>displayWorld
[ aWorld displayWorld ] in WorldState>>displayWorldSafely: in Block: [ aWorld displayWorld ]
BlockClosure>>on:do:
BlockClosure>>ifError:
WorldState>>displayWorldSafely:
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldMorph>>doOneCycle
[ [ World doOneCycle.
Processor yield.
false ] whileFalse: [  ] ] in MorphicUIManager>>spawnNewProcess in Block: [ [ World doOneCycle....
[ self value.
Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self value....