<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2014-05-25 2:39 GMT+02:00 Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi, thanks for noticing and investigating this! Seeing this now, I<br>
think we should signal an Error rather than a Warning to be more<br>
TestCase friendly but also because persisting empty packages is so<br>
painful, it should be an error, hands down. Better to force a<br>
resolution to the issue than silently persist modules of<br>
future-pain...<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>In any case, I think you accidently uncovered bugs in Tests-Monticello.<br></div><div>I'm looking at a fix for a few hours, and it's really messy.<br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
On Sat, May 24, 2014 at 6:13 PM, Nicolas Cellier<br>
<<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> Now <a href="http://build.squeak.org/job/SqueakTrunk/856/" target="_blank">http://build.squeak.org/job/SqueakTrunk/856/</a> is back to a better red<br>
> state: one that time out after 20 minutes because of the [Warning signal:<br>
> 'About to serialize an empty package.']<br>
> (like I told in my first mail and like in builds<br>
> <a href="http://build.squeak.org/job/SqueakTrunk/823/" target="_blank">http://build.squeak.org/job/SqueakTrunk/823/</a> to<br>
> <a href="http://build.squeak.org/job/SqueakTrunk/833/" target="_blank">http://build.squeak.org/job/SqueakTrunk/833/</a>)<br>
><br>
> So applying Chris' fix and repairing the update-stream was not enough to get<br>
> rid of it.<br>
><br>
> The Warning is triggered by #testMcdSerialization<br>
> It appears that (self mockDiffyVersion) has no changes...<br>
> Though, mockDiffyVersion tries to change: #a toReturn: 'a2'.<br>
> Something in this test is not working as intended, but here I'll stop for<br>
> tonight.<br>
><br>
><br>
> 2014-05-25 0:48 GMT+02:00 Nicolas Cellier<br>
> <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>>:<br>
><br>
>> OK, <a href="http://build.squeak.org" target="_blank">build.squeak.org</a>, I have to admit, you win...<br>
>> <a href="http://build.squeak.org/job/SqueakTrunk/855/console" target="_blank">http://build.squeak.org/job/SqueakTrunk/855/console</a><br>
>><br>
>><br>
>> Ddin't we see this failure already?<br>
>><br>
>><br>
>> Segmentation fault Sun May 25 00:39:10 2014<br>
>><br>
>><br>
>> Squeak VM version: 4.0-2776 #1 Thu Aug 22 10:35:56 PDT 2013 gcc 4.1.2<br>
>> [Production ITHB VM]<br>
>> Built from: CoInterpreter VMMaker.oscog-eem.331 uuid:<br>
>> 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013<br>
>> With: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid:<br>
>> 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013<br>
>> Revision: VM: r2776 <a href="http://www.squeakvm.org/svn/squeak/branches/Cog" target="_blank">http://www.squeakvm.org/svn/squeak/branches/Cog</a><br>
>> Plugins: r2545<br>
>> <a href="http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins" target="_blank">http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins</a><br>
>> Build host: Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST<br>
>> 2009 i686 i686 i386 GNU/Linux<br>
>> plugin path:<br>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776<br>
>> [default:<br>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/lib/squeak/4.0-2776/]<br>
>><br>
>><br>
>> C stack backtrace:<br>
>><br>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d051]<br>
>><br>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d228]<br>
>> [0xf57fe40c]<br>
>><br>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x80e5a59]<br>
>> [0x473c7848]<br>
>><br>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(interpret+0x1eb)[0x808107b]<br>
>><br>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(main+0x397)[0x805d717]<br>
>> /lib/i686/nosegneg/libc.so.6(__libc_start_main+0xe6)[0xb7560ca6]<br>
>><br>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805b101]<br>
>><br>
>><br>
>> Smalltalk stack dump:<br>
>> 0xbfa178a4 M LargePositiveInteger>\\ 0x4899127c: a(n) LargePositiveInteger<br>
>><br>
>><br>
>><br>
>> 2014-05-25 0:06 GMT+02:00 Nicolas Cellier<br>
>> <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>>:<br>
>><br>
>>> Ah, no, the build is still failing!<br>
>>> Since <a href="http://build.squeak.org/job/SqueakTrunk/834/" target="_blank">http://build.squeak.org/job/SqueakTrunk/834/</a> it's another problem<br>
>>> with:<br>
>>><br>
>>> MCClassDefinition>>createClass<br>
>>><br>
>>> I encountered this one while updating some of my old trunk images.<br>
>>> The definition changed in Monticello-cwp.589:<br>
>>> + inEnvironment: (CurrentEnvironment signal ifNil:<br>
>>> [superClass environment])<br>
>>> - inEnvironment: (EnvironmentRequest signal ifNil:<br>
>>> [superClass environment])<br>
>>><br>
>>> But there is no EnvironmentRequest anymore when loading this definition,<br>
>>> so we signal nil, and the load fails.<br>
>>> We would have expected this, it's just be renamed in:<br>
>>><br>
>>> Environments-cwp.47<br>
>>> Time: 22 March 2014, 7:53:17.666 pm<br>
>>> Rename EnvironmentRequest to CurrentEnvironment and use it to implement<br>
>>> Environment class>>current.<br>
>>><br>
>>> To be safe, the rename should have been performed in two stages:<br>
>>> 1) create the new class and migrate customers from the old to the new<br>
>>> one.<br>
>>> 2) remove the old one<br>
>>> It would thus have required two updates.mcm and not a single one<br>
>>> (MC lacks a semantic #rename: so it does not work like in-image-tools)<br>
>>> Unfortunately, update-cwp.48 did perform the two operations at once...<br>
>>><br>
>>> Curiously, if I take an artefact from build server and update, the<br>
>>> upgrade is then processing fine... Don't ask why.<br>
>>> Since no one complained, I told to myself that it was me not following<br>
>>> the standard process, I patched my images manually and restarted the<br>
>>> upgrade.<br>
>>> But I now see that it's not just me, there is a CI machine too using<br>
>>> Squeak trunk (anyone else???)<br>
>>><br>
>>> I have to cheat again with mcm surgery:<br>
>>> - publish an Environments-nice.47 that adds the CurrentEnvironment, but<br>
>>> not removes EnvironmentRequest<br>
>>> - patch update-cwp.48 to point to Environments-nice.47 rather than<br>
>>> Environments-cwp.47<br>
>>> That'll be in a few minutes...<br>
>>><br>
>>><br>
>>> 2014-05-24 22:58 GMT+02:00 Nicolas Cellier<br>
>>> <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>>:<br>
>>><br>
>>>><br>
>>>> 2014-05-24 22:36 GMT+02:00 Nicolas Cellier<br>
>>>> <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>>:<br>
>>>><br>
>>>>> Hi,<br>
>>>>> it seems that most of the builds are red for 2 months.<br>
>>>>> I checked the last artefact for squeak trunk:<br>
>>>>> <a href="http://build.squeak.org/job/SqueakTrunk/853/" target="_blank">http://build.squeak.org/job/SqueakTrunk/853/</a><br>
>>>>><br>
>>>>> It's still blocked with the [Warning signal: 'About to serialize an<br>
>>>>> empty package.']<br>
>>>>> With this warning, a test never time out (I don't know why exactly, but<br>
>>>>> it seems that theProcess monitored by the timeout watchdog is already<br>
>>>>> suspended by the Warning)<br>
>>>>> As a result, the tests do never complete and are aborted after 20<br>
>>>>> minutes...<br>
>>>>><br>
>>>>> Chris has fixed the problem since, but it seems that the CI does not<br>
>>>>> upload latest trunk.<br>
>>>>> Why?<br>
>>>>> It seems to be the same problem as the TestRunner: updating triggers<br>
>>>>> the same [Warning signal: 'About to serialize an empty package.']<br>
>>>>> Ah Chris, it's irony that it's you who precisely keep on fighting modal<br>
>>>>> UI ;)<br>
>>>>><br>
>>>>> Now the question: how do we escape from this situation?<br>
>>>>> Shall I cheat and modify the update that is blocking?<br>
>>>>><br>
>>>>><br>
>>>> So I decided to cheat:<br>
>>>> I brought update-eem.279 to the surgery block and reverted<br>
>>>> CommandLine-fbs.3 -> CommandLine-fbs.2<br>
>>>> CommandLine-fbs.3 tried to be smart and workaround the Warning problem,<br>
>>>> but before it had a chance to load, it precisely triggered this Warning!!!<br>
>>>> Since this update is also bringing Chris fix, let's defer<br>
>>>> CommandLine-fbs.3 to next update (eem-280) and cross fingers...<br>
>>>><br>
>>><br>
>><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>