parallel test crashing on arm (perhaps when there is a firewall)

[ViralBShah]

The parallel test is failing on arm. The chromebook by default has a firewall that refuses everything. I believe I have set it up to accept all connections. Irrespective, we shouldn't be getting a segfault, and perhaps a better error about connection refused.

     * parallel             
signal (11): Segmentation fault

signal (11): Segmentation fault
exception on 1ERROR (unhandled task failure): connect: connection refused (ECONNREFUSED)
: ERROR: connect: connection refused (ECONNREFUSED)

signal (11): Segmentation fault
Segmentation fault (core dumped)

[maleadt]

With the ABI merging soon, this test no longer segfaults but doesn't succeed (without warnings) just yet:

     * parallel             Test Failed
  Expression: et >= 1.0 && et <= 1.5
WARNING: timedwait tests delayed. et=3.225527159, isready(rr3)=true
WARNING: Forcibly interrupting busy workers
WARNING: rmprocs: process 1 not removed
 in 863.12 seconds, maxrss  105.67 MB
    SUCCESS

Looks like a harmless failure due to my Pi being horribly, horribly slow.

Or rather, timedwait being pretty damn resource intensive. The following test executes the test callback only twice on my RPi2:

function main()
    i = 0
    timedwait(10.0) do
        @time println("foobar")
        i += 1
        false
    end
    println(i)
end

main()

On my desktop, it executes 99 times, which is to be expected given the default polling interval of 0.1
This is on a typical build from master (ie. LLVM v3.7.1 selected by default, no special Make.user flags).

Haven't looked any deeper yet; is this a known issue?

Nothing really wrong with timedwait, it's just the initial compilation that slows everything down. Once the callback function is compiled, everything works as expected.

Extend the parallel subtest in question to include a warm-up call?

[nalimilan]

Extend the parallel subtest in question to include a warm-up call?

Doesn't sound like a bad idea if that fixes the test for you. Would you make a PR?

[maleadt]

Yeah, sure, I'll have a look at it. I wanted to make sure there's no policy against it (ie. "the test suite is not meant to be run on snail-like hardware").

[tkelman]

ref #9572, we already have issues on buildbots and vm's and other limited-memory scenarios, it would be good to find a way to make the test suite more reliable there.

[yuyichao]

It's funny that this is the only issue that is closed directly by the pr merge since it has partially fixes in front of the issue number....

Anyway, I think we can close this since the "crash" should be fixed. We should open new issues for new test failures.