2014-05-25 2:39 GMT+02:00 Chris Muller <asqueaker at 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.


> On Sat, May 24, 2014 at 6:13 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at 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 at 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 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/5be65b24/attachment.htm