Hi Folks,
I have had some time recently and decided to get back into Squeak. I grabbed Eliot's latest cog vm for windows and went to update my 4.5 image from the trunk. I hit a VM crash after a minute or two of processing updates. Trying several other vintages of Eliot's vm did not help, and I also went to the Squeak ftp site and grabbed the image in the 4.6 folder and attempted to update that and ran into the same problem. I am pretty sure this crash is the crash that was discussed on the list a while ago with a corrupted mcm/mcz file. I thought that it had been resolved, but maybe I misunderstood, or maybe I am missing a step here.
Anyway, the TL;DR of this mail is: How do I avoid crashing the vm when updating from the trunk on windows, or is there a place to grab a more recent vm that can be updated safely. Figuring out either of these will work for me. I am happy to post the crash dump if that will help.
Thanks for any and all help! Jeff
Did you try updating from the trunk image instead of the 4.5 image?
Best, Marcel
-- View this message in context: http://forum.world.st/Updating-4-5-or-getting-a-recent-build-of-4-6-tp478719... Sent from the Squeak - Dev mailing list archive at Nabble.com.
Oops, directly jumped to the "TL;DR" part. :D Okay, we need to fix the process of entering the trunk path... Downloading the trunk image and updating it should work fine.
Best, Marcel
-- View this message in context: http://forum.world.st/Updating-4-5-or-getting-a-recent-build-of-4-6-tp478719... Sent from the Squeak - Dev mailing list archive at Nabble.com.
Hi Marcel,
I was pretty sure that I had tried that file, but grabbed it from that link just to be sure and tried to update again, and unfortunately no luck. Here is a link to the crash dump file that is generated: https://www.dropbox.com/s/tu8wmro478xmt1t/crash.dmp?dl=0
At least for myself, all I do to reproduce is open the image using the latest Cog, go to the world menu and hit update.
Thanks for any and all help, Jeff
Hi Folks,
Just wanted to PING the list again to see if anyone had any feedback. Am I just seeing a crash that no one else is seeing and it is something with my setup, is there a safe VM version that people are using to update from the trunk image, and is anyone else able to grab the image that Marcel posted and do a successful update on the trunk?
I am just playing around with the image Marcel posted and it is just fine for getting work done, but my OCD tendencies flare up a bit knowing that I am not working with fully updated code.
Any help or at least just letting me know that this is a problem on my end rather than the trunk would be greatly appreciated.
Thanks, Jeff
Hi Jeff,
On Wed, Oct 29, 2014 at 1:06 PM, Jeff Gonis jeff.gonis@gmail.com wrote:
Hi Folks,
Just wanted to PING the list again to see if anyone had any feedback. Am I just seeing a crash that no one else is seeing and it is something with my setup, is there a safe VM version that people are using to update from the trunk image, and is anyone else able to grab the image that Marcel posted and do a successful update on the trunk?
I am just playing around with the image Marcel posted and it is just fine for getting work done, but my OCD tendencies flare up a bit knowing that I am not working with fully updated code.
Any help or at least just letting me know that this is a problem on my end rather than the trunk would be greatly appreciated.
I'm not sure whats going on. Perhaps your image has got into a strange state. I have no problems updating the 4.5 image from the all-in-one to trunk as part of the Spur image bootstrap. See http://www.squeakvm.org/svn/squeak/branches/Cog/image/buildspurtrunkimage.sh... You might try checking-out http://www.squeakvm.org/svn/squeak/branches/Cog/image and running the script to check. The script downloads an up-to-date VM, the All-in-one, changes the update repository, updates, then builds a VMMaker image and then uses that to convert the updated trunk to Spur. This has been working well for a couple of months.
HTH
---- Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Jeff,
On Wed, Oct 29, 2014 at 1:06 PM, Jeff Gonis jeff.gonis@gmail.com wrote:
Hi Folks,
Just wanted to PING the list again to see if anyone had any feedback. Am I just seeing a crash that no one else is seeing and it is something with my setup, is there a safe VM version that people are using to update from the trunk image, and is anyone else able to grab the image that Marcel posted and do a successful update on the trunk?
I am just playing around with the image Marcel posted and it is just fine for getting work done, but my OCD tendencies flare up a bit knowing that I am not working with fully updated code.
Any help or at least just letting me know that this is a problem on my end rather than the trunk would be greatly appreciated.
I'm not sure whats going on. Perhaps your image has got into a strange state. I have no problems updating the 4.5 image from the all-in-one to trunk as part of the Spur image bootstrap. See http://www.squeakvm.org/svn/squeak/branches/Cog/image/buildspurtrunkimage.sh... You might try checking-out http://www.squeakvm.org/svn/squeak/branches/Cog/image and running the script to check. The script downloads an up-to-date VM, the All-in-one, changes the update repository, updates, then builds a VMMaker image and then uses that to convert the updated trunk to Spur. This has been working well for a couple of months.
HTH
Just a caveat about the scripts Eliot mentions. Due to recent flux in the layout of the All-in-One, [at least some of] the scripts stopped working. See
http://lists.squeakfoundation.org/pipermail/vm-dev/2014-October/016726.html
Doug
-- best, Eliot
Hi Jeff,
Nice to see you on the list, and sorry for not responding earlier.
I am fairly sure that we had some things screwed up in the update stream (since resolved) and you are experiencing the effects of that. I have a feeling that most of us working with trunk images we are keeping up to date with the stream, and we may have neglected to go back and fix up whatever update maps needed to be patched in order to work around the problem.
I don't know if this will make any difference, but the latest version of the traditional interpreter VM for Windows is at
http://www.squeakvm.org/win32/ http://www.squeakvm.org/win32/release/Squeak4.10.2-2612.win32-i386.zip
Hi Folks,
Just wanted to PING the list again to see if anyone had any feedback. Am I just seeing a crash that no one else is seeing and it is something with my setup, is there a safe VM version that people are using to update from the trunk image, and is anyone else able to grab the image that Marcel posted and do a successful update on the trunk?
I am just playing around with the image Marcel posted and it is just fine for getting work done, but my OCD tendencies flare up a bit knowing that I am not working with fully updated code.
Any help or at least just letting me know that this is a problem on my end rather than the trunk would be greatly appreciated.
Thanks, Jeff
Sorry, I hit "send" by accident. What I meant to say is that the interpreter VM may get you past the crash that you experienced, or it might just crash differently. If you have the patience you can give it a try and see if it helps.
Either way, I'm pretty sure that the problem is in the update stream as opposed to the VM.
Dave
Hi Jeff,
Nice to see you on the list, and sorry for not responding earlier.
I am fairly sure that we had some things screwed up in the update stream (since resolved) and you are experiencing the effects of that. I have a feeling that most of us working with trunk images we are keeping up to date with the stream, and we may have neglected to go back and fix up whatever update maps needed to be patched in order to work around the problem.
I don't know if this will make any difference, but the latest version of the traditional interpreter VM for Windows is at
http://www.squeakvm.org/win32/ http://www.squeakvm.org/win32/release/Squeak4.10.2-2612.win32-i386.zip
Hi Folks,
Just wanted to PING the list again to see if anyone had any feedback. Am I just seeing a crash that no one else is seeing and it is something with my setup, is there a safe VM version that people are using to update from the trunk image, and is anyone else able to grab the image that Marcel posted and do a successful update on the trunk?
I am just playing around with the image Marcel posted and it is just fine for getting work done, but my OCD tendencies flare up a bit knowing that I am not working with fully updated code.
Any help or at least just letting me know that this is a problem on my end rather than the trunk would be greatly appreciated.
Thanks, Jeff
On Wed, 29 Oct 2014, Jeff Gonis wrote:
Hi Folks,
Just wanted to PING the list again to see if anyone had any feedback. Am I just seeing a crash that no one else is seeing and it is something with my setup, is there a safe VM version that people are using to update from the trunk image, and is anyone else able to grab the image that Marcel posted and do a successful update on the trunk?
I've checked your crash.dmp, and it looks interesting, especially this part:
Stack backtrace: [80126560] ??? + 0 in (null) [8008DE63] next: + 107 in CogCode [7FFF07C8] ceReturnToInterpreterTrampoline + 0 in CogCode [7FFF06F8] ceBaseFrameReturnTrampoline + 0 in CogCode
Smalltalk stack dump: 0x99553c M SocketStream>receiveData: 0x812fa8ac: a(n) SocketStream 0x99555c M SocketStream>next: 0x812fa8ac: a(n) SocketStream 0x9955ac I HTTPSocket class>httpRequest:url:headers:content:response: 0x80513ad0: a(n) HTTPSocket class 0x995cc0 I HTTPSocket class>httpGetDocument:args:accept:request: 0x80513ad0: a(n) HTTPSocket class 0x995cec M HTTPSocket class>httpGet:args:accept:request: 0x80513ad0: a(n) HTTPSocket class 0x995d24 I HTTPSocket class>httpGet:args:user:passwd: 0x80513ad0: a(n) HTTPSocket class 0x995d54 M [] in MCHttpRepository>readStreamForFileNamed:do: 0x80dfe9d8: a(n) MCHttpRepository 0x995d70 M BlockClosure>on:do: 0x812e22e4: a(n) BlockClosure 0x995d98 M [] in MCHttpRepository>displayProgress:during: 0x80dfe9d8: a(n) MCHttpRepository 0x995dc0 M [] in MorphicUIManager>displayProgress:at:from:to:during: 0x8057fb00: a(n) MorphicUIManager 0x812e9b08 w BlockClosure>on:do:
I can't tell what went wrong, but it doesn't seem like it's related to the ZipPlugin changes. Can you tell how far the update process can go? (which update map, and which package is being installed when the crash happens) Does it always crash at the same point?
Levente
I am just playing around with the image Marcel posted and it is just fine for getting work done, but my OCD tendencies flare up a bit knowing that I am not working with fully updated code.
Any help or at least just letting me know that this is a problem on my end rather than the trunk would be greatly appreciated.
Thanks, Jeff
On Wed, Oct 29, 2014 at 3:24 PM, Levente Uzonyi leves@elte.hu wrote:
I've checked your crash.dmp, and it looks interesting, especially this part:
Stack backtrace: [80126560] ??? + 0 in (null) [8008DE63] next: + 107 in CogCode [7FFF07C8] ceReturnToInterpreterTrampoline + 0 in CogCode [7FFF06F8] ceBaseFrameReturnTrampoline + 0 in CogCode
Smalltalk stack dump: 0x99553c M SocketStream>receiveData: 0x812fa8ac: a(n) SocketStream 0x99555c M SocketStream>next: 0x812fa8ac: a(n) SocketStream 0x9955ac I HTTPSocket class>httpRequest:url:headers:content:response: 0x80513ad0: a(n) HTTPSocket class 0x995cc0 I HTTPSocket class>httpGetDocument:args:accept:request: 0x80513ad0: a(n) HTTPSocket class 0x995cec M HTTPSocket class>httpGet:args:accept:request: 0x80513ad0: a(n) HTTPSocket class 0x995d24 I HTTPSocket class>httpGet:args:user:passwd: 0x80513ad0: a(n) HTTPSocket class 0x995d54 M [] in MCHttpRepository>readStreamForFileNamed:do: 0x80dfe9d8: a(n) MCHttpRepository 0x995d70 M BlockClosure>on:do: 0x812e22e4: a(n) BlockClosure 0x995d98 M [] in MCHttpRepository>displayProgress:during: 0x80dfe9d8: a(n) MCHttpRepository 0x995dc0 M [] in MorphicUIManager>displayProgress:at:from:to:during: 0x8057fb00: a(n) MorphicUIManager 0x812e9b08 w BlockClosure>on:do:
I can't tell what went wrong, but it doesn't seem like it's related to the ZipPlugin changes. Can you tell how far the update process can go? (which update map, and which package is being installed when the crash happens) Does it always crash at the same point?
Levente
Hi Levente,
So I might not be able to recreate that exact crash because following David's advice and using the Interpreter VM caused the update to succeed. Prior to that however, it appeared to always crash in the same location in a repeatable fashion. Interestingly, after completing the update with the Interpreter VM and quitting without saving, the update proceeds using the same image and the cog VM. Could some sort of caching of packages be the problem here and completing the update successfully changes this?
Of course this fact makes it hard to reproduce the issue using the image I was talking about, as it now works, but I will attempt to see if I have any other images that I can reproduce the issue with and I will post another crash dump and details if I am successful.
Thanks to everyone for your help! Jeff
Hi Jeff,
whenever you, or anyone, has an mage that repeatably crashes the VM, I'd appreciate you keeping a copy. I may not have time to look at it, it may not be a VM bug, but if the copy isn't taken we'll never know...
On Wed, Oct 29, 2014 at 3:03 PM, Jeff Gonis jeff.gonis@gmail.com wrote:
On Wed, Oct 29, 2014 at 3:24 PM, Levente Uzonyi leves@elte.hu wrote:
I've checked your crash.dmp, and it looks interesting, especially this
part:
Stack backtrace: [80126560] ??? + 0 in (null) [8008DE63] next: + 107 in CogCode [7FFF07C8] ceReturnToInterpreterTrampoline + 0 in CogCode [7FFF06F8] ceBaseFrameReturnTrampoline + 0 in CogCode
Smalltalk stack dump: 0x99553c M SocketStream>receiveData: 0x812fa8ac: a(n) SocketStream 0x99555c M SocketStream>next: 0x812fa8ac: a(n) SocketStream 0x9955ac I HTTPSocket class>httpRequest:url:headers:content:response: 0x80513ad0: a(n) HTTPSocket class 0x995cc0 I HTTPSocket class>httpGetDocument:args:accept:request: 0x80513ad0: a(n) HTTPSocket class 0x995cec M HTTPSocket class>httpGet:args:accept:request: 0x80513ad0:
a(n)
HTTPSocket class 0x995d24 I HTTPSocket class>httpGet:args:user:passwd: 0x80513ad0: a(n) HTTPSocket class 0x995d54 M [] in MCHttpRepository>readStreamForFileNamed:do:
0x80dfe9d8:
a(n) MCHttpRepository 0x995d70 M BlockClosure>on:do: 0x812e22e4: a(n) BlockClosure 0x995d98 M [] in MCHttpRepository>displayProgress:during: 0x80dfe9d8:
a(n)
MCHttpRepository 0x995dc0 M [] in MorphicUIManager>displayProgress:at:from:to:during: 0x8057fb00: a(n) MorphicUIManager 0x812e9b08 w BlockClosure>on:do:
I can't tell what went wrong, but it doesn't seem like it's related to
the
ZipPlugin changes. Can you tell how far the update process can go? (which update map, and
which
package is being installed when the crash happens) Does it always crash at the same point?
Levente
Hi Levente,
So I might not be able to recreate that exact crash because following David's advice and using the Interpreter VM caused the update to succeed. Prior to that however, it appeared to always crash in the same location in a repeatable fashion. Interestingly, after completing the update with the Interpreter VM and quitting without saving, the update proceeds using the same image and the cog VM. Could some sort of caching of packages be the problem here and completing the update successfully changes this?
Of course this fact makes it hard to reproduce the issue using the image I was talking about, as it now works, but I will attempt to see if I have any other images that I can reproduce the issue with and I will post another crash dump and details if I am successful.
Thanks to everyone for your help! Jeff
Hi Eliot,
I will try to get some images together for you that are reproducible, but in the meantime I have to head out for the evening. One thing I have noticed, looking through the crash dumps generated for all of the crashes I have seen is that either at the very end of the primitive trace, or 2 or 3 calls from the end of the primitive trace in every single crash has been **CompactCode**
This is the only similarity between the cases in terms of the primitive trace that I can see so far, because the stack dump has had a variety of different methods being processed at the time. I will work to get a reproducible image for you, but in the meantime I thought that might twig something for you.
Thanks for your time, Jeff
On Wed, Oct 29, 2014 at 4:44 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Jeff,
whenever you, or anyone, has an mage that repeatably crashes the VM, I'dappreciate you keeping a copy. I may not have time to look at it, it may not be a VM bug, but if the copy isn't taken we'll never know...
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Douglas McPherson -
Eliot Miranda -
Jeff Gonis -
Levente Uzonyi -
Marcel Taeumel