[squeak-dev] Re: New Cog VMs available

Frank Shearar frank.shearar at gmail.com
Mon Nov 17 21:56:06 UTC 2014


On 17 November 2014 21:49, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 17 November 2014 21:20, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> Hi Frank,
>>
>> On Mon, Nov 17, 2014 at 12:44 AM, Frank Shearar <frank.shearar at gmail.com>
>> wrote:
>>>
>>> On 16 November 2014 03:24, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>> > Hi All,
>>> >
>>> >     problems solved.  So new VMs available at
>>> > http://www.mirandabanda.org/files/Cog/VM/VM.r3137/.
>>>
>>> OK, so in CI this manifests (in
>>> http://build.squeak.org/job/SqueakTrunkOnSpur/101/console) as
>>> "Segmentation fault".
>>
>>
>> I htink I'm in the clear.  I see this from lines immediately preceeding the
>> launch:
>>
>> curl -sSo cogspurlinux.tgz
>> http://www.mirandabanda.org/files/Cog/VM/VM.r3133/cogspurlinuxht-14.45.3133.tgz
>>
>>
>> So I don't think you're testing 3137.  Fingers crossed.
>
> Oh, no, I thought it'd be clear I was _agreeing_ with you that 3133 was broken!
>
>> perhaps putting a cogspurlinux/squeak -version  in the script to print the
>> version before doing the proper launch would be a good idea.
>
> The scripts delete "stale" Cogs and download the version in
> lib/squeak-ci/version.rb, which - if necessary - says that it's
> installing a new version ("Installing new cogspur r.3137 (spur)" in
> http://build.squeak.org/job/SqueakTrunkOnSpur/102/console)
>
> 3137's working its way through CI now. I don't know why it didn't kick
> off earlier today, when I pushed the version change.

OK, so the good news is that 3137 happily loaded the image. The bad
news is that, like some earlier builds, there's a recursive DNU in
ImageSegment >> #restoreEndianness, kicked off by BitmapStreamTests >>
#testMatrixTransform2x3WithImageSegment

I've not tried reproducing it locally.

frank

> frank
>
>>> Currently the build conflates several tests: it tests the latest
>>> released CogSpur while trying to update the image. That means that
>>> "segmentation fault" could actually arise because of a broken VM, or
>>> from something during the update. I _think_ that we can distinguish
>>> between the two cases, because during update we should see more
>>> output, like a stack trace or similar. For instance
>>> http://build.squeak.org/job/SqueakTrunkOnSpur/100/console shows that
>>> the VM (3126) did indeed load the image, and something went wrong
>>> during an update.
>>>
>>> frank
>>>
>>
>>
>>
>> --
>> best,
>> Eliot


More information about the Squeak-dev mailing list