newly introduced problem in Pharo5.0 running headless vm (Ubuntu 14.04)
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....
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....
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 <dale.henrichs@gemtalksystems.com>:
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....
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 <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>>:
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....
Yes I saw it too. Stef Le 28/7/16 à 23:30, Dale Henrichs a écrit :
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 <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>>:
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....
participants (3)
-
Dale Henrichs -
Nicolai Hess -
stepharo