Yesterday I reported that I was using the following script combination:
./pharo Pharo.image save xxx; ./pharo xxx.image --quit --save ./boom.st
and that the MNU was being hit during the second case when I was loading
boom.st and the same thing is true today, but instead of an MNU I'm
getting a segFault and the execution of boom.st is not even getting a
chance to start as here is stdout:
foos:test> ./pharo xxx.image --quit --save ./boom.st
Segmentation fault Fri Jul 29 11:12:12 2016
/export/foos1/users/dhenrich/dev/_home/dev/clients/test/pharo-vm/pharo
pharo VM version: 5.0 #1 Wed May 4 11:54:28 CEST 2016 gcc 4.6.3
[Production Spur ITHB VM]
Built from: CoInterpreter VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016
With: StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016
And as happened yesterday saving the Pharo.image after bringing it up
interactively "fixes the problem"... and skipping the `./pharo
Pharo.image save xxx` avoids the problem as well ..
Dale
On 07/29/2016 11:04 AM, Dale Henrichs wrote:
Attached crash.dmp file ... running Ubuntu14.04 and here's a bit of
Smalltalk stack:
0xffb7d03c I FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index:
0xbc98a58: a(n) FreeTypeFace
0xffb7d064 I FreeTypeFace>create 0xbc98a58: a(n) FreeTypeFace
0xffb7d084 I FreeTypeFace>validate 0xbc98a58: a(n) FreeTypeFace
0xffb7d0a4 I FreeTypeFont>face 0xb86ade0: a(n) FreeTypeFont
0xffb7d0fc I
FreeTypeSubPixelAntiAliasedGlyphRenderer>renderStretchedGlyph:depth:subpixelPosition:font:
0x9e2b218: a(n) FreeTypeSubPixelAntiAliasedGlyphRenderer
0xffb7d130 I
FreeTypeSubPixelAntiAliasedGlyphRenderer>subGlyphOf:colorValue:mono:subpixelPosition:font:
0x9e2b218: a(n) FreeTypeSubPixelAntiAliasedGlyphRenderer
....snip....
0xbceb0b8 s WorldMorph>displayWorld
0xbceb118 s [] in WorldState>displayWorldSafely:
0xbceb178 s BlockClosure>on:do:
0xbceb1d8 s BlockClosure>ifError:
0xbceb238 s WorldState>displayWorldSafely:
0xbceb298 s WorldState>doOneCycleNowFor:
0xbceb2f8 s WorldState>doOneCycleFor:
0xbceb358 s WorldMorph>doOneCycle
0xb95ca30 s [] in MorphicUIManager>spawnNewProcess
0xb767510 s [] in BlockClosure>newProcess
vm/image combo dowloaded yesterday launches without errors, so I don't
think it's my environment that is the source of the segfault ...
I was doing a fresh build from a bash script and from the looks of the
last couple of lines it looks like that there are new changes in this
image from yesterday:
"Postscript:
Leave the line above, and replace the rest of this comment by a useful
one.
Executable statements should follow this comment, and should
be separated by periods, with no exclamation points (!!).
Be sure to put any further comments in double-quotes, like this one."
|repository|
repository := MCHttpRepository
location: 'http://smalltalkhub.com/mc/Pharo/Pharo50/main'
user: ''
password: ''.
(repository
loadVersionFromFileNamed:'ScriptLoader50-EstebanLorenzano.975.mcz') load.
ScriptLoader new update50761.
!
----End fileIn----!
----QUIT----2016-07-29T12:18:23.980837+02:00 Pharo.image priorSource:
215270!
----QUIT----2016-07-29T12:18:29.473484+02:00 Pharo.image priorSource:
234661!
If you look at the bottom of the stack you will notice that
WorldState>doOneCycle is being called and that's suspiciously similar
to the issue I reported yesterday[1] ... but a segfault this time
instead of an MNU..
I will go through the drill of trying to see which part of the script
is hitting this problem and provide more info ...
It would be nice to get a clean build sooner rather than later :)
Dale
[1] https://pharo.fogbugz.com/f/cases/18706#BugEvent.170987
