It is Environments, and it's _after_ the image is updated: first the
CI job runs update-image.st, copies this updated artifact, and in the
copy runs prepare-test-image.st. That then fails because of a
SyntaxError being thrown, saying this:

DoIt
	Smalltalk
		at: #Log
		put: [:t1 |
			| t2 |
			t2 := #Invalid literal character ->#DateAndTime value now
printString , ': ' , t1.
			FileStream stdout nextPutAll: t2;
				 nextPut: Character lf;
				 flush.
			##Transcript value cr; show: t2].

Compare that to the original source, from prepare-test-image.st in the CI job:

Smalltalk at: #Log put: [:msg | | str |
	str := DateAndTime now printString, ': ', msg.
	FileStream stdout nextPutAll: str; nextPut: Character lf; flush.
	Transcript cr; show: str].

Note the ## marks prepended to (some of) the class names. Colin? Thoughts?

frank

On 11 March 2013 22:55, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> Most likely Environments.
> The Parser problem did crash well earlier.
>
> Nicolas
>
> 2013/3/11 Frank Shearar <frank.shearar at gmail.com>:
>> They are hanging, and I haven't had a chance to run them by hand to
>> see what's going wrong. It doesn't help that we have potentially three
>> breaking things on the go right now:
>> * the Parser issue
>> * Environments upgrade
>> * my snafu with deleting/readding classes (unlikely?)
>>
>> frank
>>
>> On 11 March 2013 22:10, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>> Unfortunately, I can't check, all recent SqueakTrunk CI jobs seem to
>>> hang (timeout after 15minutes).
>>> There are quite many tests failing with last Environmental changes
>>> (AttemptToWriteReadOnlyGlobal), and this might be related.
>>> Should we increase the timeout, or is it something else that blocks the image?
>>>
>>> Nicolas
>>>
>>> 2013/3/10 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>>> I'm not sure exactly how to read the CI results, but I confirm that
>>>> the update may fail, I experienced two trunk update failure starting
>>>> at Squeak4.4-12327 on MacOS-X with latest COG VM.
>>>>
>>>> So I renewed my fix in Kernel-nice.747, changed updates 222 to 227
>>>> again, and will wait for the reports...
>>>>
>>>> Nicolas
>>>>
>>>> 2013/3/10 Frank Shearar <frank.shearar at gmail.com>:
>>>>> http://build.squeak.org/job/SqueakTrunk-OSX/88/ shows things working,
>>>>> and the trend shows that the Mac Cog seems to have always been OK.
>>>>>
>>>>> http://build.squeak.org/job/SqueakTrunk/212/ shows bad things still
>>>>> happening with the Parser. If you look at the test history (show test
>>>>> failures only on http://build.squeak.org/job/SqueakTrunk/) you'll see
>>>>> this bug's biting hard - all the only-2-failing-test builds exhibit
>>>>> the behaviour.
>>>>>
>>>>> (Why do the tests run at all when it's a failing update? I _think_
>>>>> that's because the build script is insufficiently suicidal, and ends
>>>>> up running a TrunkImage from a previous build.)
>>>>>
>>>>> frank
>>>>>
>>>>> On 10 March 2013 19:10, 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).
>>>>>> 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
>>>>>>
>>>>>
>>>
>>
>