[FR] Add Big Endian to CI

[maxsharabayko]

To test and track regression on big-endian machines, a corresponding CI action should be added to either GitHub CI or Travis CI.

Related issue #2697.

Big-endian might be available in Travis CI. See here: travis-ci/travis-ci#8869 and https://blog.travis-ci.com/2019-11-12-multi-cpu-architecture-ibm-power-ibm-z.

GitHub Action using QEMI:
https://github.com/marketplace/actions/run-on-architecture

[matoro]

After mangling the Docker configs to get IPv6 working very close to having this. The last issue is that the srt_close() calls under the ReuseAddr test suite are failing, for both IPv4 and IPv6. I don't know whether it's Docker or QEMU at fault for this or how to fix it...

https://github.com/matoro/srt/actions/runs/4876766571/jobs/8700652107

222: Test command: /home/runner/work/srt/srt/_build/test-srt "--gtest_filter=ReuseAddr.SameAddr2"
  222: Test timeout computed to be: 10000000
  222: Running main() from /home/runner/work/srt/srt/_build/googletest/googletest-src/googletest/src/gtest_main.cc
  222: Note: Google Test filter = ReuseAddr.SameAddr2
  222: [==========] Running 1 test from 1 test suite.
  222: [----------] Global test environment set-up.
  222: [----------] 1 test from ReuseAddr
  222: [ RUN      ] ReuseAddr.SameAddr2
  222: [T/S] serverSocket: creating binder socket
  222: [T/S] Listener/binder sock @985385634 added to server_pollid
  222: [T/S] Bind @985385634 to: 172.17.0.2:5000 (IPv4)
  222: [T/S] ... result 0 (expected to succeed)
  222: [T/S] serverSocket: creating listener socket
  222: [T/S] Listener/binder sock @985385633 added to server_pollid
  222: [T/S] Bind @985385633 to: 172.17.0.2:5000 (IPv4)
  222: [T/S] ... result 0 (expected to succeed)
  222: [T/S] Wait 10s for acceptance on @985385633 ...
  222: [T/C] Creating client socket
  222: [T/C] Connecting to: 172.17.0.2:5000 (IPv4)
  222: [T/S] Accepted from: 172.17.0.2:55808
  222: [T/S] Wait for data reception...
  222: [T/C] Waiting for connection readiness...
  222: [T/C] Client exit
  222: [T/S] closing sockets: ACP:@985385631 LSN:@985385633 CLR:@985385632 ...
  222: [T/S] joining client async...
  222: [T/S] waiting for cleanup of @985385634 up to 10s
  222: [T/S] @985385634 dissolved after 1.004s
  222: [T/S] serverSocket: creating listener socket
  222: [T/S] Listener/binder sock @985385630 added to server_pollid
  222: [T/S] Bind @985385630 to: 172.17.0.2:5000 (IPv4)
  222: [T/S] ... result 0 (expected to succeed)
  222: [T/S] Wait 10s for acceptance on @985385630 ...
  222: [T/C] Creating client socket
  222: [T/C] Connecting to: 172.17.0.2:5000 (IPv4)
  222: [T/S] Accepted from: 172.17.0.2:44625
  222: [T/S] Wait for data reception...
  222: [T/C] Waiting for connection readiness...
  222: [T/C] Client exit
  222: [T/S] closing sockets: ACP:@985385628 LSN:@985385630 CLR:@985385629 ...
  222: /home/runner/work/srt/srt/test/test_reuseaddr.cpp:414: Failure
  222: Expected: (srt_close(g_client_sock)) != (SRT_ERROR), actual: -1 vs -1
  222: [T/S] waiting for cleanup of @985385630 up to 10s
  222: [T/S] @985385630 dissolved after 1.01s
  222: [  FAILED  ] ReuseAddr.SameAddr2 (2337 ms)

Same for ReuseAddr.SameAddrV6, and then one different:

 227: Test command: /home/runner/work/srt/srt/_build/test-srt "--gtest_filter=ReuseAddr.ProtocolVersion6"
  227: Test timeout computed to be: 10000000
  227: Running main() from /home/runner/work/srt/srt/_build/googletest/googletest-src/googletest/src/gtest_main.cc
  227: Note: Google Test filter = ReuseAddr.ProtocolVersion6
  227: [==========] Running 1 test from 1 test suite.
  227: [----------] Global test environment set-up.
  227: [----------] 1 test from ReuseAddr
  227: [ RUN      ] ReuseAddr.ProtocolVersion6
  227: [T/S] serverSocket: creating listener socket
  227: [T/S] Listener/binder sock @634509449 added to server_pollid
  227: [T/S] Bind @634509449 to: 0.0.0.0:5000 (IPv4)
  227: [T/S] ... result 0 (expected to succeed)
  227: [T/S] Listener/binder sock @634509448 added to server_pollid
  227: [T/S] Bind @634509448 to: :::5000 (IPv6)
  227: [T/S] ... result 0 (expected to succeed)
  227: [T/S] Wait 10s for acceptance on @634509449 ...
  227: [T/C] Creating client socket
  227: [T/C] Connecting to: 127.0.0.1:5000 (IPv4)
  227: [T/S] Accepted from: 127.0.0.1:41231
  227: [T/S] Wait for data reception...
  227: [T/C] Waiting for connection readiness...
  227: [T/C] Client exit
  227: [T/S] closing sockets: ACP:@634509446 LSN:@634509449 CLR:@634509447 ...
  227: [T/S] joining client async...
  227: [T/S] Wait 10s for acceptance on @634509448 ...
  227: [T/C] Creating client socket
  227: [T/C] Connecting to: ::1:5000 (IPv4)
  227: [T/S] Accepted from: ::1:40380
  227: [T/S] Wait for data reception...
  227: [T/C] Waiting for connection readiness...
  227: /home/runner/work/srt/srt/test/test_reuseaddr.cpp:231: Failure
  227: Expected equality of these values:
  227:   wlen
  227:     Which is: 2
  227:   1
  227: [T/C] Client exit
  227: [T/S] closing sockets: ACP:@634509444 LSN:@634509448 CLR:@634509445 ...
  227: [T/S] joining client async...
  227: [T/S] waiting for cleanup of @634509449 up to 10s
  227: [T/S] @634509449 dissolved after 1.017s
  227: [T/S] waiting for cleanup of @634509448 up to 10s
  227: [T/S] @634509448 dissolved after 1.005s
  227: [  FAILED  ] ReuseAddr.ProtocolVersion6 (2342 ms)

[matoro]

For reference, this is what I'm working with: https://github.com/matoro/srt/blob/master/.github/workflows/cxx11-ubuntu.yaml

If uraimo/run-on-arch-action#93 were implemented it would run x86_64 in the same Docker setup which would help narrow down the culprit, but it's not yet unfortunately.

[ethouris]

I am observing more and more tests failing on TestConnection.QuickClose test and the symptom is that there's -1 returned from srt_close on just one of the sockets (out of 60). Might be some regression although hard to say from what. Normally this is tolerable (this is not a problem that a socket disappeared just before you wanted to close it anyway), but OTOH it might be not a sure thing that the socket was properly destroyed.

[matoro]

I am observing more and more tests failing on TestConnection.QuickClose test and the symptom is that there's -1 returned from srt_close on just one of the sockets (out of 60). Might be some regression although hard to say from what. Normally this is tolerable (this is not a problem that a socket disappeared just before you wanted to close it anyway), but OTOH it might be not a sure thing that the socket was properly destroyed.

Very possibly the same issue. QEMU slows down execution by an order of magnitude so possibly a race condition here that's triggered when running too slowly?

If you manage to figure it out, please let me know so I can rebase it in and try again.