[Vm-dev] CI status

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Oct 27 08:33:38 UTC 2020


Le mar. 27 oct. 2020 à 00:00, Eliot Miranda <eliot.miranda at gmail.com> a
écrit :

>
>
>
> On Oct 26, 2020, at 2:53 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
> 
>
>
> Le lun. 26 oct. 2020 à 16:26, Eliot Miranda <eliot.miranda at gmail.com> a
> écrit :
>
>>
>>
>> On Oct 26, 2020, at 7:22 AM, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>> 
>>
>>
>> Le lun. 26 oct. 2020 à 15:11, Eliot Miranda <eliot.miranda at gmail.com> a
>> écrit :
>>
>>>
>>> Hi Nicolas,
>>>
>>> On Oct 26, 2020, at 6:59 AM, Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>
>>> 
>>> Hi all,
>>> I have restored (I think) the green status of minheadless build.
>>>
>>>
>>> Thank you so much!
>>>
>>> We could eventually authorize failure of all those builds, or restrict
>>> the number of flavours that we build (it takes really loooong time before
>>> we get CI feedback).
>>> But if we abandon all those now, I fear that we never catch up; it's a
>>> one way ticket. IMO there are still interesting ideas to take, even if
>>> development has continued in Pharo fork...
>>>
>>>
>>> One approach might be to split them into “essential” and “nice to have”
>>> so we get faster feedback from the “essential” set.
>>>
>>> +1, but I do not know how to configure the CI like that...
>>
>>> Now the next failing build on travis is about squeak.cog.v3. Did some
>>> incompatible VM change took place?
>>>
>>> For example
>>> https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/jobs/738831149
>>>
>>> ######################################################
>>>
>>> # Squeak-4.6 on Travis CI (2278.23)                  #
>>>
>>> # 3401 Tests with 5 Failures and 0 Errors in 112.13s #
>>>
>>> ######################################################
>>>
>>> #########################
>>>
>>> # 5 tests did not pass: #
>>>
>>> #########################
>>>
>>> SUnitToolBuilderTests
>>> 837fef_266b
>>>
>>>  ✗ #testHandlingNotification (10023ms)
>>>
>>> TestValueWithinFix
>>> 2a65cb_266b
>>>
>>>  ✗ #testValueWithinTimingBasic (1005ms)
>>> e9a7ab_266b
>>>
>>>  ✗ #testValueWithinTimingNestedInner (1001ms)
>>> c57415_266b
>>>
>>>  ✗ #testValueWithinTimingNestedOuter (1002ms)
>>> e89da3_266b
>>>
>>>  ✗ #testValueWithinTimingRepeat (3004ms)
>>>
>>>   Executed 3401 Tests with 5 Failures and 0 Errors in 112.13s.
>>>
>>> To reproduce the failed build locally, download smalltalkCI, and try to run something like:
>>>
>>> 	bin/smalltalkci -s Squeak-4.6 --headfull /path/to/.smalltalk.ston
>>>
>>> Could these test failures be nothing to do with the VM but instead to do
>>> with the (growing) divergence between trunk/spur and Squeak 4.6?
>>>
>>> _,,,^..^,,,_ (phone)
>>>
>> No idea...
>> I've downloaded a Squeak4.6-15102.image, compiled a squeak.cog.v3 on
>> windows10, and the test pass...
>> I will retry on other OSes this evening (the test fails on linux...).
>>
>>
>> At least one of those failures is a timeout.  So it may just be that the
>> CI box is slow.  We might cure the issues by lengthening the timeouts.  Or
>> we could make them expected failures, especially if we can find out some
>> way to identify that we’re running on a CI box.
>>
>
> There's something fishy...
> Only the linux brand times out.
> The test waits 10 times 200msec, so should last about 2s.
>     [SUnitToolBuilderTests new testHandlingNotification] timeToRun.
> does answer something around 2048 on macos brand, but 7706 on linux (???).
>
> The build.itimerheartbeat brand does complete the test in about 2020ms so
> it's OK.
>
> squeak.cog.spur/build/squeak also performs the test in about 7700ms in an
> updated trunk image...
> So it's not just squeak.cog.v3 here...
> I can only run linux thru a VM (Parallels), so if someone can confirm the
> behavior on some native linux
>
>
> Ah!  Is the kernel older than 2.6.4 (IIRC)?  If so, the heartbeat thread
> doesn’t work properly because the vm doesn’t have permission or ability to
> set the heartbeat thread’s priority.
>

No, it's an ubuntu 16:

$ uname -a
Linux ubuntu 4.4.0-193-generic #224-Ubuntu SMP Tue Oct 6 17:15:28 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux

I hopefully have the correct setup for authorizing thread priority

$ cat /etc/security/limits.d/squeak.conf
*       hard    rtprio  2
*       soft    rtprio  2

I have no warning in the console telling that "pthread_setschedparam failed
"...

So I don't know what's going on. Can someone reproduce?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20201027/e16b3fbf/attachment.html>


More information about the Vm-dev mailing list