Hi - I'm pretty sure I'm having the same problem Phillipe had/described in this message: http://forum.world.st/Zinc-crashing-image-at-start-up-td3785797.html At least the PharoDebug.log is the same. It happens on both the most recent Cog and interpreter VM. Is there a way to recover from this? I could follow Sean's instructions from this thread if necessary: http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.ht... Or is there a way to extract changes from a changes file for one image into another image? I'd rather fix the broken image but if its not possible I'd then just try to load those changes I don't have. Thanks for any guidance you can provide. Paul
Hi Paul, On 30 Dec 2011, at 04:57, Paul DeBruicker wrote:
I'm pretty sure I'm having the same problem Phillipe had/described in this message:
http://forum.world.st/Zinc-crashing-image-at-start-up-td3785797.html
At least the PharoDebug.log is the same. It happens on both the most recent Cog and interpreter VM.
I am sorry for your troubles. This is also related to http://code.google.com/p/pharo/issues/detail?id=4768 which is fixed in in 1.4 and in 1.3 #13314. If you are using 1.3 it is always a good idea to manually upgrade Zn to its latest version (the version is 1.3 is quite old). When using 'running' Zn servers based Seaside adaptors that need to survive image saves, I would advise using ZnManagingMultiThreadedServer like this: ZnZincServerAdaptor new port: 8080; serverClass: ZnManagingMultiThreadedServer; start Adaptors based on ZnManagingMultiThreadedServer will track and close all open worker connections and socket streams when needed.
Is there a way to recover from this?
I could follow Sean's instructions from this thread if necessary:
http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.ht...
Or is there a way to extract changes from a changes file for one image into another image? I'd rather fix the broken image but if its not possible I'd then just try to load those changes I don't have.
Thanks for any guidance you can provide.
I am no expert at reviving crashing images, maybe others can help. Regards, Sven
On Fri, Dec 30, 2011 at 4:57 AM, Paul DeBruicker <pdebruic@gmail.com> wrote:
Hi -
I'm pretty sure I'm having the same problem Phillipe had/described in this message:
At least the PharoDebug.log is the same. It happens on both the most recent Cog and interpreter VM.
Is there a way to recover from this?
I could follow Sean's instructions from this thread if necessary:
http://forum.world.st/Fwd-**Oops-I-put-a-halt-in-a-** startup-method-td3800729.html<http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.ht...>
Or is there a way to extract changes from a changes file for one image into another image? I'd rather fix the broken image but if its not possible I'd then just try to load those changes I don't have.
Yes, you can drag and frop the .changes of an image XXX into a running image of YYY and you should be able to browse changes and recover them. Of course you can also open .changes with a text editor and recover what you want, but is less funny ;)
Thanks for any guidance you can provide.
Paul
-- Mariano http://marianopeck.wordpress.com
In 1.4 ArrayedCollection we have this self class isPointers | self class isWords not ifTrue: [^self]. in >>restoreEndianness but this in
writeOn:
(self class isPointers or: [ self class isWords not ]) ifTrue: [^ self ]. It gets called once per task in both and should be a correct method, right ? The former does not even look correct at a glance. I have no time today to go check if this odd duplication remains in 2.0 as I must run
participants (4)
-
Mariano Martinez Peck -
Paul DeBruicker -
Robert Shiplett -
Sven Van Caekenberghe