[Vm-dev] Spur corrupts large images when saving

Esteban Lorenzano estebanlm at gmail.com
Sat Apr 23 07:17:09 UTC 2016


Hi, 

> On 23 Apr 2016, at 01:10, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> Hi Yuriy, Hi Esteban,
> 
> On Fri, Apr 22, 2016 at 12:17 AM, Yuriy Tymchuk <yuriy.tymchuk at me.com <mailto:yuriy.tymchuk at me.com>> wrote:
>  
> The script can be still used to reproduce the issue with the latest vm
> 
>> On 07 Mar 2016, at 22:32, Yuriy Tymchuk <yuriy.tymchuk at me.com <mailto:yuriy.tymchuk at me.com>> wrote:
>> 
>> Dear vm developers,
>> 
>> I’ve encountered multiple times an issue when my images cannot be opened after saving (only on spur). I think that this happens when image is large, and the following script results in a corrupt image almost 100%:
>> 
>> 
>> curl get.pharo.org/50+vmLatest <http://get.pharo.org/50+vm> | bash
>> 
>> ./pharo Pharo.image --no-default-preferences eval --save \
>>   "Smalltalk globals at: #ReallyBigArray put: (ByteArray new: 1024*1024*1000). 'Done'"
>> 
>> ./pharo Pharo.image printVersion
>> 
>> 
>> The last line is there just to make image do something and for me it fails all the times. I hope that this can help to troubleshoot the issue with the vm.
>> 
>> Also here are my system & hardware specs:
>> 
>> System Version:	OS X 10.11.3 (15D21)
>> Model Identifier:	MacBookPro11,5
>> Processor Name:	Intel Core i7
>> Processor Speed:	2.8 GHz
>> Total Number of Cores:	4
>> Memory:	16 GB
>> 
>> Cheers!
>> Uko
> 
> 
> I've reproduced this with the pharo vm.  I see an issue not with the image but with the platform subsystem.  Here's the error message I see after the image is successfully saved with the ~ 1Gb byte array:
>  
> McStalker.Pharo$ ls -lh Pharo.image 
> -rw-r--r--@ 1 eliot  staff   1.0G Apr 22 15:52 Pharo.image
> McStalker.Pharo$ ./pharo-vm/Pharo.app/Contents/MacOS/Pharo Pharo.image 
> objc[44476]: autorelease pool page 0x21ce000 corrupted
>   magic 0x0100040b 0x03000000 0x214a9d00 0x00000003
>   pthread 0x9f75b00
> 
> Illegal instruction: 4
> 
> but if I start the image with a "Pharo" VM compiled from the Cog source tree (Pharo in quotes because the VM is missing a number of plugins) the system starts up and is usable.
> 
> McStalker.Pharo$ pharocfvm -version
> /Users/eliot/oscogvm/build.macos32x86/pharo.cog.spur/CocoaFast.app/Contents/MacOS/Pharo
> 5.0 5.0.3678 Mac OS X built on Apr 22 2016 11:40:09 PDT Compiler: 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) [Production Spur VM]
> CoInterpreter VMMaker.oscog-eem.1832 uuid: 3e4d6e88-f60d-4a01-930d-7c5895b8a86a Apr 22 2016
> StackToRegisterMappingCogit VMMaker.oscog-eem.1832 uuid: 3e4d6e88-f60d-4a01-930d-7c5895b8a86a Apr 22 2016
> VM: r3678 http://www.squeakvm.org/svn/squeak/branches/Cog <http://www.squeakvm.org/svn/squeak/branches/Cog> Date: 2016-04-22 11:26:57 -0700
> Plugins: r3639 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins <http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins>
> 
> I can confirm that the problem is with the Pharo platforms/iOS subsystem, and not for example,e, plugins.  If I include the plains from the official pharo-vm in the Pharo VM built from the Cog branch sources, the image loads.
> 
> Somehow we need to merge the two subsystems.  i.e. we need to merge http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/iOS <http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/iOS> with the pharo equivalent.  For example, Pharo's tree supports -headless but the Cog branch does not, the Cog branch supports 64-bits and -version, Pharo's does not.  Volunteers?

I agree that we need to converge (too many waist of efforts), and I’m slowly working on that (you’d be surprised how few our changes are now compared to last year(s))… 
iOS is a bit more difficult because we changed some important things, but it will be done anyway… 
Anyway, anyone willing to help is very welcome :)

… as I told before, it would help me HUGE if the announced migration to git/github happens soon :)
I’m willing to help in that migration if you want, it should be an easy task (I saw Fabio is doing some tests already…)

cheers!
Esteban

> 
> _,,,^..^,,,_
> best, Eliot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160423/89f6e477/attachment-0001.htm


More information about the Vm-dev mailing list