2014-05-25 18:34 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2014-05-25 2:39 GMT+02:00 Chris Muller asqueaker@gmail.com:
Hi, thanks for noticing and investigating this! Seeing this now, I
think we should signal an Error rather than a Warning to be more TestCase friendly but also because persisting empty packages is so painful, it should be an error, hands down. Better to force a resolution to the issue than silently persist modules of future-pain...
In any case, I think you accidently uncovered bugs in Tests-Monticello. I'm looking at a fix for a few hours, and it's really messy.
Hooray! After publishing Tests-nice.297 there is now a trunk CI job that finished http://build.squeak.org/job/SqueakTrunk/857/
Now we can see we have some regressions... How could we live without CI before?
Of course, for dissecting which change introduced which regression after a 2 month interrupt, that's going to be more pain than necessary...
On Sat, May 24, 2014 at 6:13 PM, Nicolas Cellier
nicolas.cellier.aka.nice@gmail.com wrote:
Now http://build.squeak.org/job/SqueakTrunk/856/ is back to a better
red
state: one that time out after 20 minutes because of the [Warning
signal:
'About to serialize an empty package.'] (like I told in my first mail and like in builds http://build.squeak.org/job/SqueakTrunk/823/ to http://build.squeak.org/job/SqueakTrunk/833/)
So applying Chris' fix and repairing the update-stream was not enough
to get
rid of it.
The Warning is triggered by #testMcdSerialization It appears that (self mockDiffyVersion) has no changes... Though, mockDiffyVersion tries to change: #a toReturn: 'a2'. Something in this test is not working as intended, but here I'll stop
for
tonight.
2014-05-25 0:48 GMT+02:00 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
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@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:
- 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@gmail.com:
2014-05-24 22:36 GMT+02:00 Nicolas Cellier nicolas.cellier.aka.nice@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...