<div dir="ltr"><div><div><div><div>Now <a href="http://build.squeak.org/job/SqueakTrunk/856/">http://build.squeak.org/job/SqueakTrunk/856/</a> is back to a better red state: one that time out after 20 minutes because of the [Warning  signal: &#39;About to <span>serialize</span> an empty package.&#39;]<br>
(like I told in my first mail and like in builds <a href="http://build.squeak.org/job/SqueakTrunk/823/">http://build.squeak.org/job/SqueakTrunk/823/</a> to <a href="http://build.squeak.org/job/SqueakTrunk/833/">http://build.squeak.org/job/SqueakTrunk/833/</a>)<br>
<br></div><div>So applying Chris&#39; fix and repairing the update-stream was not enough to get rid of it.<br></div><div><br></div>The Warning is triggered by #testMcdSerialization<br></div>It appears that (self mockDiffyVersion) has no changes...<br>
</div>Though, mockDiffyVersion tries to  change: #a toReturn: &#39;a2&#39;.<br></div>Something in this test is not working as intended, but here I&#39;ll stop for tonight.<br><div><div><div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014-05-25 0:48 GMT+02:00 Nicolas Cellier <span dir="ltr">&lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><pre>OK, <a href="http://build.squeak.org" target="_blank">build.squeak.org</a>, I have to admit, you win... <a href="http://build.squeak.org/job/SqueakTrunk/855/console" target="_blank">http://build.squeak.org/job/SqueakTrunk/855/console</a><br>

</pre><pre>Ddin&#39;t we see this failure already?<br></pre><pre><br>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 <a href="http://www.squeakvm.org/svn/squeak/branches/Cog" target="_blank">http://www.squeakvm.org/svn/squeak/branches/Cog</a>
Plugins: r2545 <a href="http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins" target="_blank">http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins</a>
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&gt;\\ 0x4899127c: a(n) LargePositiveInteger
</pre><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-25 0:06 GMT+02:00 Nicolas Cellier <span dir="ltr">&lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>&gt;</span>:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>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&#39;s another problem with:<br>


<pre>MCClassDefinition&gt;&gt;createClass</pre>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: [superClass environment])<br>
-                       inEnvironment: (EnvironmentRequest signal ifNil: [superClass environment])<br><br>But there is no EnvironmentRequest anymore when loading this definition, so we signal nil, and the load fails.<br>



</div><div>We would have expected this, it&#39;s just be renamed in:<br></div><div><br>Environments-cwp.47<br>
Time: 22 March 2014, 7:53:17.666 pm<br><div>
Rename <span>EnvironmentRequest</span> to CurrentEnvironment and use it to implement <span>Environment</span> class&gt;&gt;current.<br><br></div>To be safe, the rename should have been performed in two stages:<br>
</div><div>1) create the new class and migrate customers from the old to the new one.<br></div><div>2) remove the old one<br></div><div>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>


</div><div></div><div>Unfortunately, update-cwp.48 did perform the two operations at once...<br><br></div><div>Curiously, if I take an artefact from build server and update, the upgrade is then processing fine... Don&#39;t ask why.<br>


</div>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.<br>But I now see that it&#39;s not just me, there is a CI machine too using Squeak trunk (anyone else???)<br>


<br></div>I have to cheat again with mcm surgery:<br></div>- publish an Environments-nice.47 that adds the CurrentEnvironment, but not removes EnvironmentRequest<br></div>- patch update-cwp.48 to point to Environments-nice.47 rather than Environments-cwp.47<br>


</div><div>That&#39;ll be in a few minutes...<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-24 22:58 GMT+02:00 Nicolas Cellier <span dir="ltr">&lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>&gt;</span>:<div>

<div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2014-05-24 22:36 GMT+02:00 Nicolas Cellier <span dir="ltr">&lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>&gt;</span>:<div>


<div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi,<br></div>it seems that most of the builds are red for 2 months.<br>



</div>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></div>It&#39;s still blocked with the [Warning  signal: &#39;About to <span>serialize</span> an empty package.&#39;]<br></div>With this warning, a test never time out (I don&#39;t know why exactly, but it seems that theProcess monitored by the timeout watchdog is already suspended by the Warning)<br>




As a result, the tests do never complete and are aborted after 20 minutes...<br><br></div>Chris has fixed the problem since, but it seems that the CI does not upload latest trunk.<br></div>Why?<br></div>It seems to be the same problem as the TestRunner: updating triggers the same [Warning  signal: &#39;About to <span>serialize</span> an empty package.&#39;]<br>




</div>Ah Chris, it&#39;s irony that it&#39;s you who precisely keep on fighting modal UI ;)<br><br></div>Now the question: how do we escape from this situation?<br></div>Shall I cheat and modify the update that is blocking?<br>




<div><div><br><br></div></div></div></blockquote></div></div><div>So I decided to cheat:<br></div><div>I brought update-eem.279 to the surgery block and reverted CommandLine-fbs.3 -&gt; CommandLine-fbs.2<br>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!!!<br>



</div><div>Since this update is also bringing Chris fix, let&#39;s defer CommandLine-fbs.3 to next update (eem-280) and cross fingers...<br></div></div><br></div></div>
</blockquote></div></div></div><br></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div></div></div></div></div>