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
On 07/28/2016 02:24 PM, Nicolai Hess wrote:
Hi Dale,
I think this problem already exists in Pharo 5.0, see bug report
18706
<https://pharo.fogbugz.com/f/cases/18706/Build-of-Pharo5-is-broken>
Build of Pharo5 is broken
2016-07-28 22:58 GMT+02:00 Dale Henrichs
<[email protected]
<mailto:[email protected]>>:
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 <http://boom.st>
The contents of boom.st <http://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 <http://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....
