<br><br>On Mon, Mar 11, 2013 at 4:40 PM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>> 2013/3/12 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
>> On Mon, Mar 11, 2013 at 4:26 PM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>>>> On 11 March 2013 23:12, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
>>>> On Sun, Mar 10, 2013 at 12:10 PM, Nicolas Cellier<br>>>>> <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>>>>>> OK, see the VM thread, I now think that problems does not come from<br>
>>>>> COG, but from ClassBuilder which in some cases fail to clean a cache<br>>>>>> (primitive 116).<br>>>>>> The problem does not show up in interpreter VM thanks to primitive 119<br>
>>>>> (this primitives does not unlink send in cogit).<br>>>>><br>>>>> it does unlink sends, but only for that selector. But is it really<br>>>>> the case that it is a missing cache flush or is it a bug in Cog with<br>
>>>> its cache flushing? I realised the way to test this is to try the<br>>>>> Stack VM and see if it crashes or not. I just tried that but now<br>>>>> neither Cog nor the Stack VM crash although both fail the load with an<br>
>>>> MNU of #do: to UndefinedObject in Environment>>bindingOf:ifAbsent:.<br>>>>> So how do I get the system back to a state where I can reproduce the<br>>>>> Cog crash to compare the Stack and Cog VMs with each other?<br>
>>>><br>>>>> (Apologies for being unresponsive; I've just moved into a new<br>>>>> apartment and only got my internet connection yesterday afternoon; at<br>>>>> least its fast (for the states) :) ).<br>
>>><br>>>> I'm reasonably sure that this guy -<br>>>> <a href="http://build.squeak.org/job/SqueakTrunk/208/">http://build.squeak.org/job/SqueakTrunk/208/</a> - has images that are<br>>>> pre-latest-Environments code. That's #12519 at any rate.<br>
>><br>>> That's not the problem. I have an image that crashed last week. I<br>>> need a way of not applying all the updates. Bert's version worked to<br>>> exclude some updates but others are creeping in. Time is limited so I<br>
>> hoped for a quick fix :(<br>><br>> We could craft a special mixture of package in an update map and put<br>> it in inbox for example.<br>> But which packages exactly ?<br>> What do you want to test ?<br>
<br>The state that causes Cog to hard crash by reading off the end of the Parser instance because the old version of <span class="Apple-style-span" style="border-collapse:collapse;font-family:arial,sans-serif;font-size:14px">Parser>>parse:cue:noPattern:ifFail: on the stack uses the pre-reshape inst var offsets.</span><br>
<br><br>See Bert's message: Filtering out updates > 222 used to ensure the crash.<br><br><blockquote class="webkit-indent-blockquote" style="margin:0 0 0 40px;border:none;padding:0px">On Tue, Feb 26, 2013 at 11:44 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
* I downloaded Squeak4.4-12327.zip from <a href="http://ftp.squeak.org/current_stable/">http://ftp.squeak.org/current_stable/</a><br>* in preferences, change Update URL to trunk<br>* load updates<br>* Cog crashes (last log entry is Compiler-nice.256)<br>
* Interpreter does not crash<br>This is on Mac with current Cog 4.0.2692.<br>Phhh, is there any way to load a specific update? What's the update number/id? Of course I'm too late to this party to debug the VM crash :(<br>
Before updating, in MCMcmUpdater class>>updateListFor: insert this before the return:<br> updateList := updateList reject: [:ea | ea key > 222].</blockquote><br>><br>> Nicolas<br>><br>>>><br>>>> frank<br>
>>><br>>>>>> I have attempted a ClassBuilder fix and posted new updates from<br>>>>>> nice-222 to cwp-227.<br>>>>>><br>>>>>> Can I please ask our testers contribution once again?<br>
>>>>><br>>>>>> Nicolas<br>>>>>><br>>>>>> 2013/3/8 Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>>:<br>
>>>>>> 2013/3/8 Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>>:<br>>>>>>>><br>>>>>>>> On 2013-03-08, at 10:55, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
>>>>>>><br>>>>>>>>> On 7 March 2013 23:25, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>>>>>>>>>> On 7 March 2013 23:11, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
>>>>>>>>>> On 2013-03-07, at 23:42, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>>>>>>>>>>><br>>>>>>>>>>>>>> On 6 March 2013 15:59, Ken G. Brown <<a href="mailto:kbrown@mac.com">kbrown@mac.com</a>> wrote:<br>
>>>>>>>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to<br>>>>>>>>>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by<br>
>>>>>>>>>>>>>> abandoning and trying the update again, it apparently completes to 12511.<br>>>>>>>>>>>>>>><br>>>>>>>>>>>>>>> Ken G. Brown<br>
>>>>>>>>>>>>>><br>>>>>>>>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during<br>>>>>>>>>>>>>>>> the same update-nice-223, then trying again from what had already been<br>
>>>>>>>>>>>>>>> loaded, got the following during the same update, during compiling<br>>>>>>>>>>>>>>>> SMLoader-fbs-78 as before:<br>
>>>>>>>>>>><br>>>>>>>>>>>> What I find strange about all this is that we take a 4.4-12327 image<br>>>>>>>>>>>> and whatever the latest Cog is and update it all the way without any<br>
>>>>>>>>>>> probems quite a few times a day on the CI server.<br>>>>>>>>>>>><br>>>>>>>>>>>> frank<br>>>>>>>>>>><br>
>>>>>>>>>> Looks like it's an intermittent problem, unfortunately:<br>>>>>>>>>>><br>>>>>>>>>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697.<br>
>>>>>>>>>><br>>>>>>>>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again.<br>>>>>>>>>>><br>
>>>>>>>>>> BOOM. Cog crash. Didn't save the log unfortunately.<br>>>>>>>>>>><br>>>>>>>>>>> Tried again. Update, switch to trunk, update again. No crash. What?!<br>
>>>>>>>>>><br>>>>>>>>>>> Once more. Update, switch to trunk, update. Crash! See below.<br>>>>>>>>>>><br>>>>>>>>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place.<br>
>>>>>>>>>><br>>>>>>>>>>> So it does crash, just not always. But it's been more than 50% in my case.<br>>>>>>>>>><br>>>>>>>>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44;<br>
>>>>>>>>> they switch to trunk and update just like that. Which I would have<br>>>>>>>>>> thought would make no difference...<br>>>>>>>>><br>>>>>>>>> Actually, I lie. Here's an example of the CI jobs hitting the same<br>
>>>>>>>> issue: <a href="http://build.squeak.org/job/SqueakTrunk/204/console">http://build.squeak.org/job/SqueakTrunk/204/console</a> And further<br>>>>>>>>> if you look at <a href="http://build.squeak.org/job/SqueakTrunk/">http://build.squeak.org/job/SqueakTrunk/</a> and choose to<br>
>>>>>>>> see the failing tests you'll see times (say around build #184) where<br>>>>>>>>> the test failure count is unusually low. And<br>>>>>>>>> <a href="http://build.squeak.org/job/SqueakTrunk/buildTimeTrend">http://build.squeak.org/job/SqueakTrunk/buildTimeTrend</a> shows grey<br>
>>>>>>>> streaks where builds die.<br>>>>>>>><br>>>>>>>> Curious that it still runs the tests at all if the update failed ...<br>>>>>>>><br>
>>>>>>> So Cog crashes, but has someone tried to replicate this on an interpreter?<br>>>>>>>><br>>>>>>>> - Bert -<br>>>>>>>><br>>>>>>><br>
>>>>>> I think that the problem comes form COG which tries to use an obsolete<br>>>>>>> method sent AFTER the recompilation of Parser which is not the<br>>>>>>> expected behavior.<br>
>>>>>> I have triggered such kind of strange behavior that does not happen on<br>>>>>>> an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog<br>>>>>>> VM Crash on Windows'<br>
>>>>>> For me, it must be related to a cache that is not cleaned-up, I don't know why.<br>>>>>>><br>>>>>>> Nicolas<br>>>>>><br>>>>><br>>>>><br>
>>>><br>>>>> --<br>>>>> best,<br>>>>> Eliot<br>>>>><br>>>><br>>><br>>><br>>><br>>> --<br>>> best,<br>>> Eliot<br>>><br>
><br><br><br><br>-- <br>best,<br>Eliot<br>