Spur corrupts large images when saving

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Spur corrupts large images when saving

Uko2
 
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%:



./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
Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Eliot Miranda-2
 
Hi Yuriy,

    what's the version info in that VM?  I expect this is the same bug I fixed in

CogVM binaries as per VMMaker.oscog-eem.1679/r3602
 ...
Fix start up of images containing >= 16 segments.  The old code assumed
numSegments < 16 and failed to grow the segment records, resulting in objects
in segments greater than 15 to not be swizzled, and a resulting crash.


_,,,^..^,,,_ (phone)

On Mar 7, 2016, at 1:32 PM, Yuriy Tymchuk <[hidden email]> 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%:



./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
Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

stephane ducasse-2
In reply to this post by Uko2
 
Yes I got the same last week.
I loaded SciSmalltalk and just program one hour and my image went to 1.4 Gb
I could not load it. 

Stef 

On 07 Mar 2016, at 22:32, Yuriy Tymchuk <[hidden email]> 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%:



./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

Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Uko2
In reply to this post by Eliot Miranda-2
 
Yes, I’m using VMMaker.oscog-EstebanLorenzano.1676

Thank you

On 08 Mar 2016, at 06:08, Eliot Miranda <[hidden email]> wrote:

Hi Yuriy,

    what's the version info in that VM?  I expect this is the same bug I fixed in

CogVM binaries as per VMMaker.oscog-eem.1679/r3602
 ...
Fix start up of images containing >= 16 segments.  The old code assumed
numSegments < 16 and failed to grow the segment records, resulting in objects
in segments greater than 15 to not be swizzled, and a resulting crash.


_,,,^..^,,,_ (phone)

On Mar 7, 2016, at 1:32 PM, Yuriy Tymchuk <[hidden email]> 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%:



./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

Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

EstebanLM
 
can you try with vmLatest, to check if Eliot change fix it?

Esteban

On 08 Mar 2016, at 11:43, Yuriy Tymchuk <[hidden email]> wrote:

Yes, I’m using VMMaker.oscog-EstebanLorenzano.1676

Thank you

On 08 Mar 2016, at 06:08, Eliot Miranda <[hidden email]> wrote:

Hi Yuriy,

    what's the version info in that VM?  I expect this is the same bug I fixed in

CogVM binaries as per VMMaker.oscog-eem.1679/r3602
 ...
Fix start up of images containing >= 16 segments.  The old code assumed
numSegments < 16 and failed to grow the segment records, resulting in objects
in segments greater than 15 to not be swizzled, and a resulting crash.


_,,,^..^,,,_ (phone)

On Mar 7, 2016, at 1:32 PM, Yuriy Tymchuk <[hidden email]> 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%:



./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


Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Uko2
 
Same issue happens with:

VMMaker.oscog-nice.1713

Does the script that I provided crash only for me?

Cheers.
Uko

On 08 Mar 2016, at 13:48, Esteban Lorenzano <[hidden email]> wrote:

can you try with vmLatest, to check if Eliot change fix it?

Esteban

On 08 Mar 2016, at 11:43, Yuriy Tymchuk <[hidden email]> wrote:

Yes, I’m using VMMaker.oscog-EstebanLorenzano.1676

Thank you

On 08 Mar 2016, at 06:08, Eliot Miranda <[hidden email]> wrote:

Hi Yuriy,

    what's the version info in that VM?  I expect this is the same bug I fixed in

CogVM binaries as per VMMaker.oscog-eem.1679/r3602
 ...
Fix start up of images containing >= 16 segments.  The old code assumed
numSegments < 16 and failed to grow the segment records, resulting in objects
in segments greater than 15 to not be swizzled, and a resulting crash.


_,,,^..^,,,_ (phone)

On Mar 7, 2016, at 1:32 PM, Yuriy Tymchuk <[hidden email]> 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%:



./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



Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Eliot Miranda-2
In reply to this post by Uko2
 
Hi Yuriy,

_,,,^..^,,,_ (phone)

On Mar 8, 2016, at 2:43 AM, Yuriy Tymchuk <[hidden email]> wrote:

Yes, I’m using VMMaker.oscog-EstebanLorenzano.1676

and how about the VMs in http://www.mirandabanda.org/files/Cog/VM/latest/?  If you're on Mac you would use http://www.mirandabanda.org/files/Cog/VM/latest/CogPharoSpur.app-16.08.3632.tgz.  Just check if it starts up.  The VM is missing some plugins and support libraries.  But it definitely has the problem fixed.

Also Yuriy, could you purine of the images that won't start up somewhere where I can download it to take a look?


Thank you

On 08 Mar 2016, at 06:08, Eliot Miranda <[hidden email]> wrote:

Hi Yuriy,

    what's the version info in that VM?  I expect this is the same bug I fixed in

CogVM binaries as per VMMaker.oscog-eem.1679/r3602
 ...
Fix start up of images containing >= 16 segments.  The old code assumed
numSegments < 16 and failed to grow the segment records, resulting in objects
in segments greater than 15 to not be swizzled, and a resulting crash.


_,,,^..^,,,_ (phone)

On Mar 7, 2016, at 1:32 PM, Yuriy Tymchuk <[hidden email]> 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%:



./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

Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Eliot Miranda-2
In reply to this post by Uko2
 
Yuriy, Steph,

On Mar 8, 2016, at 2:43 AM, Yuriy Tymchuk <[hidden email]> wrote:

Yes, I’m using VMMaker.oscog-EstebanLorenzano.1676

ignore my earlier response.  You need to use a newer VM.  The problem was fixed in VMMaker.oscog-eem.1679 so move to a newer VM.

_,,,^..^,,,_ (phone)


Thank you

On 08 Mar 2016, at 06:08, Eliot Miranda <[hidden email]> wrote:

Hi Yuriy,

    what's the version info in that VM?  I expect this is the same bug I fixed in

CogVM binaries as per VMMaker.oscog-eem.1679/r3602
 ...
Fix start up of images containing >= 16 segments.  The old code assumed
numSegments < 16 and failed to grow the segment records, resulting in objects
in segments greater than 15 to not be swizzled, and a resulting crash.


_,,,^..^,,,_ (phone)

On Mar 7, 2016, at 1:32 PM, Yuriy Tymchuk <[hidden email]> 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%:



./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

Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

EstebanLM
 

On 08 Mar 2016, at 16:30, Eliot Miranda <[hidden email]> wrote:

Yuriy, Steph,

On Mar 8, 2016, at 2:43 AM, Yuriy Tymchuk <[hidden email]> wrote:

Yes, I’m using VMMaker.oscog-EstebanLorenzano.1676

ignore my earlier response.  You need to use a newer VM.  The problem was fixed in VMMaker.oscog-eem.1679 so move to a newer VM.

he also tested on VMMaker.oscog-nice.1713 :)



_,,,^..^,,,_ (phone)


Thank you

On 08 Mar 2016, at 06:08, Eliot Miranda <[hidden email]> wrote:

Hi Yuriy,

    what's the version info in that VM?  I expect this is the same bug I fixed in

CogVM binaries as per VMMaker.oscog-eem.1679/r3602
 ...
Fix start up of images containing >= 16 segments.  The old code assumed
numSegments < 16 and failed to grow the segment records, resulting in objects
in segments greater than 15 to not be swizzled, and a resulting crash.


_,,,^..^,,,_ (phone)

On Mar 7, 2016, at 1:32 PM, Yuriy Tymchuk <[hidden email]> 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%:



./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


Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

stephane ducasse-2
In reply to this post by Eliot Miranda-2
 
Thanks I will check (now I have a huge deadline for this evening) Mooc videos.

Stef
On 08 Mar 2016, at 16:30, Eliot Miranda <[hidden email]> wrote:

Yuriy, Steph,

On Mar 8, 2016, at 2:43 AM, Yuriy Tymchuk <[hidden email]> wrote:

Yes, I’m using VMMaker.oscog-EstebanLorenzano.1676

ignore my earlier response.  You need to use a newer VM.  The problem was fixed in VMMaker.oscog-eem.1679 so move to a newer VM.

_,,,^..^,,,_ (phone)


Thank you

On 08 Mar 2016, at 06:08, Eliot Miranda <[hidden email]> wrote:

Hi Yuriy,

    what's the version info in that VM?  I expect this is the same bug I fixed in

CogVM binaries as per VMMaker.oscog-eem.1679/r3602
 ...
Fix start up of images containing >= 16 segments.  The old code assumed
numSegments < 16 and failed to grow the segment records, resulting in objects
in segments greater than 15 to not be swizzled, and a resulting crash.


_,,,^..^,,,_ (phone)

On Mar 7, 2016, at 1:32 PM, Yuriy Tymchuk <[hidden email]> 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%:



./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


Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Uko2
In reply to this post by Uko2
 
The script can be still used to reproduce the issue with the latest vm

On 07 Mar 2016, at 22:32, Yuriy Tymchuk <[hidden email]> 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%:



./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

Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Tudor Girba-2

Thanks for reporting. Indeed, I just encountered a similar situation with a 900Mb image.

Cheers,
Doru


> On Apr 22, 2016, at 9:17 AM, Yuriy Tymchuk <[hidden email]> wrote:
>
> The script can be still used to reproduce the issue with the latest vm
>
>> On 07 Mar 2016, at 22:32, Yuriy Tymchuk <[hidden email]> 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 | 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
>

--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."








Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Eliot Miranda-2
In reply to this post by Uko2
 
Hi Yuriy, Hi Esteban,

On Fri, Apr 22, 2016 at 12:17 AM, Yuriy Tymchuk <[hidden email]> wrote:
 
The script can be still used to reproduce the issue with the latest vm

On 07 Mar 2016, at 22:32, Yuriy Tymchuk <[hidden email]> 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%:



./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 Date: 2016-04-22 11:26:57 -0700

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 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?

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

EstebanLM
 
Hi, 

On 23 Apr 2016, at 01:10, Eliot Miranda <[hidden email]> wrote:

Hi Yuriy, Hi Esteban,

On Fri, Apr 22, 2016 at 12:17 AM, Yuriy Tymchuk <[hidden email]> wrote:
 
The script can be still used to reproduce the issue with the latest vm

On 07 Mar 2016, at 22:32, Yuriy Tymchuk <[hidden email]> 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%:



./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 Date: 2016-04-22 11:26:57 -0700

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 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

Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Bert Freudenberg
 
On 23.04.2016, at 09:17, Esteban Lorenzano <[hidden email]> wrote:

… 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…)

Actually, Fabio did a complete migration while squeakvm.org was out. This had a full history of all SVN commits.

“Unfortunately” Ian fixed the server too soon so development continued on SVN, so now the git repo is again out-of-date.

We would need to freeze the SVN, do the migration again, and use git from that point on. It would involve a day of downtime, but doing this sooner than later would be a good thing.

Any opinions on what date may be good?

- Bert -




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Clément Béra
 
On Sat, Apr 23, 2016 at 12:54 PM, Bert Freudenberg <[hidden email]> wrote:
 
On 23.04.2016, at 09:17, Esteban Lorenzano <[hidden email]> wrote:

… 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…)

Actually, Fabio did a complete migration while squeakvm.org was out. This had a full history of all SVN commits.

“Unfortunately” Ian fixed the server too soon so development continued on SVN, so now the git repo is again out-of-date.

We would need to freeze the SVN, do the migration again, and use git from that point on. It would involve a day of downtime, but doing this sooner than later would be a good thing.

Any opinions on what date may be good?

I'd love to see that happening next week.

I would like to see the merge of the iOS branches ASAP. I am *really really really* pissed at this drag'n'drop bug in the current state of Eliot's branch because I drag'n'drop things all the time and it creates me a lot of crashes.

But Eliot and Nicolas have to decide, they're the ones committing the most on the svn currently.


- Bert -





Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Nicolas Cellier
 


2016-04-23 13:56 GMT+02:00 Clément Bera <[hidden email]>:
 
On Sat, Apr 23, 2016 at 12:54 PM, Bert Freudenberg <[hidden email]> wrote:
 
On 23.04.2016, at 09:17, Esteban Lorenzano <[hidden email]> wrote:

… 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…)

Actually, Fabio did a complete migration while squeakvm.org was out. This had a full history of all SVN commits.

“Unfortunately” Ian fixed the server too soon so development continued on SVN, so now the git repo is again out-of-date.

We would need to freeze the SVN, do the migration again, and use git from that point on. It would involve a day of downtime, but doing this sooner than later would be a good thing.


doesn't gitsvn help?
 
Any opinions on what date may be good?

I'd love to see that happening next week.

I would like to see the merge of the iOS branches ASAP. I am *really really really* pissed at this drag'n'drop bug in the current state of Eliot's branch because I drag'n'drop things all the time and it creates me a lot of crashes.

But Eliot and Nicolas have to decide, they're the ones committing the most on the svn currently.


for myself I'm fine with github.
Nicolas


- Bert -







Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Nicolas Cellier
 


2016-04-23 14:22 GMT+02:00 Nicolas Cellier <[hidden email]>:


2016-04-23 13:56 GMT+02:00 Clément Bera <[hidden email]>:
 
On Sat, Apr 23, 2016 at 12:54 PM, Bert Freudenberg <[hidden email]> wrote:
 
On 23.04.2016, at 09:17, Esteban Lorenzano <[hidden email]> wrote:

… 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…)

Actually, Fabio did a complete migration while squeakvm.org was out. This had a full history of all SVN commits.

“Unfortunately” Ian fixed the server too soon so development continued on SVN, so now the git repo is again out-of-date.

We would need to freeze the SVN, do the migration again, and use git from that point on. It would involve a day of downtime, but doing this sooner than later would be a good thing.


doesn't gitsvn help?
 
Any opinions on what date may be good?

I'd love to see that happening next week.

I would like to see the merge of the iOS branches ASAP. I am *really really really* pissed at this drag'n'drop bug in the current state of Eliot's branch because I drag'n'drop things all the time and it creates me a lot of crashes.

But Eliot and Nicolas have to decide, they're the ones committing the most on the svn currently.


for myself I'm fine with github.
Nicolas

I should have said more than fine, enthusiasm!
BTW could someone point me to Fabio repository, I failed to find it.
 

- Bert -








Reply | Threaded
Open this post in threaded view
|

Re: Spur corrupts large images when saving

Max Leske
In reply to this post by Uko2
 

On 23 Apr 2016, at 14:47, [hidden email] wrote:

BTW could someone point me to Fabio repository, I failed to find it.


Max
Reply | Threaded
Open this post in threaded view
|

svn git bridge? (was: Spur corrupts large images when saving)

David T. Lewis
In reply to this post by Nicolas Cellier
 
On Sat, Apr 23, 2016 at 02:22:29PM +0200, Nicolas Cellier wrote:

>  
> 2016-04-23 13:56 GMT+02:00 Cl??ment Bera <[hidden email]>:
>
> >
> > On Sat, Apr 23, 2016 at 12:54 PM, Bert Freudenberg <[hidden email]>
> > wrote:
> >
> >>
> >> Actually, Fabio did a complete migration while squeakvm.org was out.
> >> This had a full history of all SVN commits.
> >>
> >> ???Unfortunately??? Ian fixed the server too soon so development continued on
> >> SVN, so now the git repo is again out-of-date.
> >>
> >> We would need to freeze the SVN, do the migration again, and use git from
> >> that point on. It would involve a day of downtime, but doing this sooner
> >> than later would be a good thing.
> >>
> >>
> doesn't gitsvn help?
>

I have to admit that I did not even know that an active git svn bridge
was possible. It sounds like this it might be very helpful.

It would be great to have the advantages of git for development, and
it could also be helpful to be able to have the squeakvm.org repo updated
periodically from git. There are portions of the platforms tree that Eliot
has been able to make identical for oscog and trunk, and this seems like
a worthwhile effort to continue.

Another possible advantage is that Ian's cmake build process takes advantage
of the SVN revision numbering, and it would be good to make sure this stays
healthy as development proceeds (it's a lot nicer than autotools).

Eliot, do you have a view on this?

Dave

123