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

[Maximiliano Tabacman via Pharo-users]

--- Begin Message ---

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/pharopharo 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 2016With: 
StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 
16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016Revision: 
https://github.com/pharo-project/pharo-vm.git Commit: 
9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 By: 
GitHub <nore...@github.com> Jenkins build #594Build 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/Linuxplugin 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 class0xffe9ea14 M MacStore 
class(Behavior)>allSubclassesDo: 0xa3393f0: a(n) MacStore class0xffe9ea34 M [] 
in UnixStore class(Behavior)>allSubclassesDo: 0xa339380: a(n) UnixStore 
class0xffe9ea58 M Array(SequenceableCollection)>do: 0x9ded798: a(n) 
Array0xffe9ea7c I UnixStore class(Class)>subclassesDo: 0xa339380: a(n) 
UnixStore class0xffe9ea98 M UnixStore class(Behavior)>allSubclassesDo: 
0xa339380: a(n) UnixStore class0xffe9eab8 M [] in DiskStore 
class(Behavior)>allSubclassesDo: 0xa339310: a(n) DiskStore class0xffe9eadc M 
Array(SequenceableCollection)>do: 0x9ded710: a(n) Array0xffe9d7c8 I DiskStore 
class(Class)>subclassesDo: 0xa339310: a(n) DiskStore class0xffe9d7e4 M 
DiskStore class(Behavior)>allSubclassesDo: 0xa339310: a(n) DiskStore 
class0xffe9d800 M DiskStore class>activeClass 0xa339310: a(n) DiskStore 
class0xffe9d81c M DiskStore class>currentFileSystem 0xa339310: a(n) DiskStore 
class0xffe9d834 M DiskStore class>current 0xa339310: a(n) DiskStore 
class0xffe9d84c M DiskStore class>delimiter 0xa339310: a(n) DiskStore 
class0xffe9d864 M DiskStore(FileSystemStore)>delimiter 0x9deb478: a(n) 
DiskStore0xffe9d884 M DiskStore(FileSystemStore)>pathFromString: 0x9deb478: 
a(n) DiskStore0xffe9d8a4 M DiskStore>defaultWorkingDirectory 0x9deb478: a(n) 
DiskStore0xffe9d8bc M FileSystem>initializeWithStore: 0x9deb488: a(n) 
FileSystem0xffe9d8dc M FileSystem class>store: 0xa2e2978: a(n) FileSystem 
class0xffe9d8f8 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.

--- End Message ---