OK, build.squeak.org, I have to admit, you win...
http://build.squeak.org/job/SqueakTrunk/855/console

Ddin't we see this failure already?


Segmentation fault Sun May 25 00:39:10 2014


Squeak VM version: 4.0-2776 #1 Thu Aug 22 10:35:56 PDT 2013 gcc 4.1.2
[Production ITHB VM]
Built from: CoInterpreter VMMaker.oscog-eem.331 uuid:
37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013
With: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid:
84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013
Revision: VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins
Build host: Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST
2009 i686 i686 i386 GNU/Linux
plugin path: /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776
[default: /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/lib/squeak/4.0-2776/]


C stack backtrace:
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d051]
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d228]
[0xf57fe40c]
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x80e5a59]
[0x473c7848]
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(interpret+0x1eb)[0x808107b]
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(main+0x397)[0x805d717]
/lib/i686/nosegneg/libc.so.6(__libc_start_main+0xe6)[0xb7560ca6]
/var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805b101]


Smalltalk stack dump:
0xbfa178a4 M LargePositiveInteger>\\ 0x4899127c: a(n) LargePositiveInteger



2014-05-25 0:06 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> Ah, no, the build is still failing!
> Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem
> with:
>
> MCClassDefinition>>createClass
>
> I encountered this one while updating some of my old trunk images.
> The definition changed in Monticello-cwp.589:
> +                       inEnvironment: (CurrentEnvironment signal ifNil:
> [superClass environment])
> -                       inEnvironment: (EnvironmentRequest signal ifNil:
> [superClass environment])
>
> But there is no EnvironmentRequest anymore when loading this definition,
> so we signal nil, and the load fails.
> We would have expected this, it's just be renamed in:
>
> Environments-cwp.47
> Time: 22 March 2014, 7:53:17.666 pm
> Rename EnvironmentRequest to CurrentEnvironment and use it to implement
> Environment class>>current.
>
> To be safe, the rename should have been performed in two stages:
> 1) create the new class and migrate customers from the old to the new one.
> 2) remove the old one
> It would thus have required two updates.mcm and not a single one
> (MC lacks a semantic #rename: so it does not work like in-image-tools)
> Unfortunately, update-cwp.48 did perform the two operations at once...
>
> Curiously, if I take an artefact from build server and update, the upgrade
> is then processing fine... Don't ask why.
> Since no one complained, I told to myself that it was me not following the
> standard process, I patched my images manually and restarted the upgrade.
> But I now see that it's not just me, there is a CI machine too using
> Squeak trunk (anyone else???)
>
> I have to cheat again with mcm surgery:
> - publish an Environments-nice.47 that adds the CurrentEnvironment, but
> not removes EnvironmentRequest
> - patch update-cwp.48 to point to Environments-nice.47 rather than
> Environments-cwp.47
> That'll be in a few minutes...
>
>
> 2014-05-24 22:58 GMT+02:00 Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
>
>
>> 2014-05-24 22:36 GMT+02:00 Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com>:
>>
>> Hi,
>>> it seems that most of the builds are red for 2 months.
>>> I checked the last artefact for squeak trunk:
>>> http://build.squeak.org/job/SqueakTrunk/853/
>>>
>>> It's still blocked with the [Warning signal: 'About to serialize an
>>> empty package.']
>>> With this warning, a test never time out (I don't know why exactly, but
>>> it seems that theProcess monitored by the timeout watchdog is already
>>> suspended by the Warning)
>>> As a result, the tests do never complete and are aborted after 20
>>> minutes...
>>>
>>> Chris has fixed the problem since, but it seems that the CI does not
>>> upload latest trunk.
>>> Why?
>>> It seems to be the same problem as the TestRunner: updating triggers the
>>> same [Warning signal: 'About to serialize an empty package.']
>>> Ah Chris, it's irony that it's you who precisely keep on fighting modal
>>> UI ;)
>>>
>>> Now the question: how do we escape from this situation?
>>> Shall I cheat and modify the update that is blocking?
>>>
>>>
>>> So I decided to cheat:
>> I brought update-eem.279 to the surgery block and reverted
>> CommandLine-fbs.3 -> CommandLine-fbs.2
>> CommandLine-fbs.3 tried to be smart and workaround the Warning problem,
>> but before it had a chance to load, it precisely triggered this Warning!!!
>> Since this update is also bringing Chris fix, let's defer
>> CommandLine-fbs.3 to next update (eem-280) and cross fingers...
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140525/3e6f2ea7/attachment-0001.htm