Smalltalk › Pharo › Pharo Smalltalk Developers

Re: [Pharo-users] Image freezes on Linux if it was previously saved on Windows

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Nicolai Hess-3-2

Re: [Pharo-users] Image freezes on Linux if it was previously saved on Windows

Hm,

I don't know what exactly happens.

It seems this behavior started with Pharo 50574.

Since that image version, the UUIDGenerator will be reset on startup.

Maybe the initialization of the uuidgenerator (or the random seed) will access the filesystem and at this step the file system initialization

traps into an infinit loop. What I don't understand is, why this only happens when the image was saved on a windows platform and

reopened on a unix platform. Maybe, saving the image (or the shutDownList) does not fully cleanup the platform settings.

Please open a bug entry.

2016-06-25 17:17 GMT+02:00 Maximiliano Tabacman via Pharo-users <[hidden email]>:

---------- Weitergeleitete Nachricht ----------
From: Maximiliano Tabacman <[hidden email]>
To: Any Question About Pharo Is Welcome <[hidden email]>
Cc:
Date: Sat, 25 Jun 2016 15:16:27 +0000 (UTC)
Subject: Image freezes on Linux if it was previously saved on Windows
Hi. I am not sure if this issue is known, or what files to provide to help fix it.
In the latest image (60112, but my guess is that this will happen with all Pharo 6 images) if I download a clean latest image, start Pharo on Windows, save the image, then copy it to a Linux environment, and try to start it, the image freezes even before displaying the workspace (I get an unresponsive black and white box in Linux, only killable through xkill command).
I am sure this did not happen back with Pharo 5.
If I output "./pharo Image.image > log.txt" I end up with a huge file since there seems to be an infinite loop while trying to determine the FileStore to use.

The first lines of this output file, before going into the loop, are:

out of memory

/home/theUser/Downloads/Pharo6/pharo
pharo VM version: 5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM]
Built from: CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
With: StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
Revision: https://github.com/pharo-project/pharo-vm.git Commit: 9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 By: GitHub <[hidden email]> Jenkins build #594
Build host: Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux
plugin path: /home/theUser/Downloads/Pharo6/ [default: /home/theUser/Downloads/Pharo6/]

C stack backtrace & registers:
*./pharo[0x80c133c]
./pharo(error+0x17)[0x80c1547]
./pharo[0x809a26c]
./pharo[0x809a301]
./pharo[0x809a53d]
./pharo[0x809bf13]
./pharo[0x80a6b61]
./pharo[0x80ae4ca]
./pharo[0x80ae6ba]
./pharo[0x80af07f]
./pharo[0x80afcf4]
./pharo(ceSendsupertonumArgs+0x1d8)[0x80b0098]
[0x990008d]
[0x990de03]
[0x99090af]
[0x9900b70]
[0x990dda3]
[0x990de03]
[0x99090af]
[0x9900b40]
[0xffe95808]

Smalltalk stack dump:
0xffe9e9f8 I MacStore class(Class)>subclassesDo: 0xa3393f0: a(n) MacStore class
0xffe9ea14 M MacStore class(Behavior)>allSubclassesDo: 0xa3393f0: a(n) MacStore class
0xffe9ea34 M [] in UnixStore class(Behavior)>allSubclassesDo: 0xa339380: a(n) UnixStore class
0xffe9ea58 M Array(SequenceableCollection)>do: 0x9ded798: a(n) Array
0xffe9ea7c I UnixStore class(Class)>subclassesDo: 0xa339380: a(n) UnixStore class
0xffe9ea98 M UnixStore class(Behavior)>allSubclassesDo: 0xa339380: a(n) UnixStore class
0xffe9eab8 M [] in DiskStore class(Behavior)>allSubclassesDo: 0xa339310: a(n) DiskStore class
0xffe9eadc M Array(SequenceableCollection)>do: 0x9ded710: a(n) Array
0xffe9d7c8 I DiskStore class(Class)>subclassesDo: 0xa339310: a(n) DiskStore class
0xffe9d7e4 M DiskStore class(Behavior)>allSubclassesDo: 0xa339310: a(n) DiskStore class
0xffe9d800 M DiskStore class>activeClass 0xa339310: a(n) DiskStore class
0xffe9d81c M DiskStore class>currentFileSystem 0xa339310: a(n) DiskStore class
0xffe9d834 M DiskStore class>current 0xa339310: a(n) DiskStore class
0xffe9d84c M DiskStore class>delimiter 0xa339310: a(n) DiskStore class
0xffe9d864 M DiskStore(FileSystemStore)>delimiter 0x9deb478: a(n) DiskStore
0xffe9d884 M DiskStore(FileSystemStore)>pathFromString: 0x9deb478: a(n) DiskStore
0xffe9d8a4 M DiskStore>defaultWorkingDirectory 0x9deb478: a(n) DiskStore
0xffe9d8bc M FileSystem>initializeWithStore: 0x9deb488: a(n) FileSystem
0xffe9d8dc M FileSystem class>store: 0xa2e2978: a(n) FileSystem class
0xffe9d8f8 M DiskStore class>currentFileSystem 0xa339310: a(n) DiskStore class

... and so on...from #currentFileSystem to #store: and again...

Thanks for any feedback and/or insight on how I should proceed to avoid this from happening, or what bug should I monitor to know when this might be fixed.