On 11 March 2013 23:30, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> On Mon, Mar 11, 2013 at 4:26 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> On 11 March 2013 23:12, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>> On Sun, Mar 10, 2013 at 12:10 PM, Nicolas Cellier
>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>> OK, see the VM thread, I now think that problems does not come from
>>>> COG, but from ClassBuilder which in some cases fail to clean a cache
>>>> (primitive 116).
>>>> The problem does not show up in interpreter VM thanks to primitive 119
>>>> (this primitives does not unlink send in cogit).
>>>
>>> it does unlink sends, but only for that selector.  But is it really
>>> the case that it is a missing cache flush or is it a bug in Cog with
>>> its cache flushing?  I realised the way to test this is to try the
>>> Stack VM and see if it crashes or not.  I just tried that but now
>>> neither Cog nor the Stack VM crash although both fail the load with an
>>> MNU of #do: to UndefinedObject in Environment>>bindingOf:ifAbsent:.
>>> So how do I get the system back to a state where I can reproduce the
>>> Cog crash to compare the Stack and Cog VMs with each other?
>>>
>>> (Apologies for being unresponsive; I've just moved into a new
>>> apartment and only got my internet connection yesterday afternoon; at
>>> least its fast (for the states) :) ).
>>
>> I'm reasonably sure that this guy -
>> http://build.squeak.org/job/SqueakTrunk/208/ - has images that are
>> pre-latest-Environments code. That's #12519 at any rate.
>
> That's not the problem.  I have an image that crashed last week.  I
> need a way of not applying all the updates.  Bert's version worked to
> exclude some updates but others are creeping in. Time is limited so I
> hoped for a quick fix :(

Sorry, Eliot. Didn't mean to add to the noise. It's just that we found
a second breakage in the updates (or a second serious bug that
recently appeared in an update, rather), so I assumed your mail was
related to this _new_ thing and not Nicolas' Parser thing.

frank

>> frank
>>
>>>> I have attempted a ClassBuilder fix and posted new updates from
>>>> nice-222 to cwp-227.
>>>>
>>>> Can I please ask our testers contribution once again?
>>>>
>>>> Nicolas
>>>>
>>>> 2013/3/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>>>> 2013/3/8 Bert Freudenberg <bert at freudenbergs.de>:
>>>>>>
>>>>>> On 2013-03-08, at 10:55, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>>>
>>>>>>> On 7 March 2013 23:25, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>>>>> On 7 March 2013 23:11, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>>>>>> On 2013-03-07, at 23:42, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>>> On 6 March 2013 15:59, Ken G. Brown <kbrown at mac.com> wrote:
>>>>>>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to
>>>>>>>>>>>>> 12332, updating to Trunk  fails at first attempt in the same place, then by
>>>>>>>>>>>>> abandoning and trying the update again, it apparently completes to 12511.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Ken G. Brown
>>>>>>>>>>>>>
>>>>>>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during
>>>>>>>>>>>>>> the same update-nice-223, then trying again from what had already been
>>>>>>>>>>>>>> loaded, got the following during the same update, during compiling
>>>>>>>>>>>>>> SMLoader-fbs-78 as before:
>>>>>>>>>>
>>>>>>>>>> What I find strange about all this is that we take a 4.4-12327 image
>>>>>>>>>> and whatever the latest Cog is and update it all the way without any
>>>>>>>>>> probems quite a few times a day on the CI server.
>>>>>>>>>>
>>>>>>>>>> frank
>>>>>>>>>
>>>>>>>>> Looks like it's an intermittent problem, unfortunately:
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again.
>>>>>>>>>
>>>>>>>>> BOOM. Cog crash. Didn't save the log unfortunately.
>>>>>>>>>
>>>>>>>>> Tried again. Update, switch to trunk, update again. No crash. What?!
>>>>>>>>>
>>>>>>>>> Once more. Update, switch to trunk, update. Crash! See below.
>>>>>>>>>
>>>>>>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place.
>>>>>>>>>
>>>>>>>>> So it does crash, just not always. But it's been more than 50% in my case.
>>>>>>>>
>>>>>>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44;
>>>>>>>> they switch to trunk and update just like that. Which I would have
>>>>>>>> thought would make no difference...
>>>>>>>
>>>>>>> Actually, I lie. Here's an example of the CI jobs hitting the same
>>>>>>> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further
>>>>>>> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to
>>>>>>> see the failing tests you'll see times (say around build #184) where
>>>>>>> the test failure count is unusually low. And
>>>>>>> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey
>>>>>>> streaks where builds die.
>>>>>>
>>>>>> Curious that it still runs the tests at all if the update failed ...
>>>>>>
>>>>>> So Cog crashes, but has someone tried to replicate this on an interpreter?
>>>>>>
>>>>>> - Bert -
>>>>>>
>>>>>
>>>>> I think that the problem comes form COG which tries to use an obsolete
>>>>> method sent AFTER the recompilation of Parser which is not the
>>>>> expected behavior.
>>>>> I have triggered such kind of strange behavior that does not happen on
>>>>> an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog
>>>>> VM Crash on Windows'
>>>>> For me, it must be related to a cache that is not cleaned-up, I don't know why.
>>>>>
>>>>> Nicolas
>>>>
>>>
>>>
>>>
>>> --
>>> best,
>>> Eliot
>>>
>>
>
>
>
> --
> best,
> Eliot
>