Project

General

Profile

Misc #16360

Enabling IBM PowerPC/Z cases in Travis CI

Added by jaruga (Jun Aruga) 17 days ago. Updated 3 days ago.

Status:
Open
Priority:
Normal
Assignee:
-
[ruby-core:95910]

Description

We added arm64-linux and arm32-linux cases to Travis CI by the ticket.
The arm32-linux case is going to be stable after this pull-request will be merged.

So, I would like to talk about this topic.
Currently Travis CI has following 4 multiple CPU architectures cases.

  • x86_64-linux (Intel, 64-bit, Little-endian)
  • arm64-linux (ARM, 64-bit, Little-endian)
  • i686-linux (Intel, 32-bit, Little-endian)
  • arm32-linux (ARM, 32-bit, Little-endian)

And a exciting news came from Travis CI this month.
Now Travis supports arch: ppc64le and arch: s390x as arch: arm64 as well.

Build your open source projects on IBM Power and IBM Z CPU architecture
https://blog.travis-ci.com/2019-11-12-multi-cpu-architecture-ibm-power-ibm-z

So, how do you think about adding following 2 cases to Travis CI too?

  • ppc64le-linux (IBM PowerPC, 64-bit, Little-endian)
  • s390x-linux (IBM Z/Linux One, 64-bit, Big-endian)

ppc64le, s390x use cases in Ruby project

  • Searching tickets in Redmine, there were some architecture specific issues in the past.
  • https://rubyci.org/ has s390x. But it seems it does not have ppc64le.
  • s390x is a big-endian. It looks good to check the big-endian specific issue.

ppc64le, s390x use cases in Linux distributions

For example Ubuntu is supporting ppc64le, s390x, providing the container image.

https://hub.docker.com/_/ubuntu
Supported architectures: (more info)
amd64, arm32v7, arm64v8, i386, ppc64le, s390x

Fedora project is supporting ppc64le, s390x too.

https://hub.docker.com/_/fedora
Supported architectures: (more info)
amd64, arm32v7, arm64v8, ppc64le, s390x

Are you interested in adding the ppc64le and s390x test cases to Travis CI?

History

Updated by shyouhei (Shyouhei Urabe) 14 days ago

Hello. It is definitely a good idea to enhance our CI. But that alone does not improve the code quality. We need someone to fix issues.

Maybe we need a platform maintainer first.

Updated by jaruga (Jun Aruga) 6 days ago

shyouhei (Shyouhei Urabe) wrote:

Hello. It is definitely a good idea to enhance our CI. But that alone does not improve the code quality. We need someone to fix issues.

Maybe we need a platform maintainer first.

Hello. I agree with it.

Someone, do you have any idea to find the platform maintainers to help us?

Maybe like this?

  • arm64 (+ arm32): person A
  • ppc64le: person B
  • s390x: person C

Updated by naruse (Yui NARUSE) 4 days ago

Rei Odaira will work as best effort for both ppc64le and s390x.
https://twitter.com/ReiOdaira/status/1202383090611556353

So it's interesting to add them to CI.

Updated by ReiOdaira (Rei Odaira) 3 days ago

I'm happy to work for ppc64le and s390x. In the last few years, the number of the platform-specific issues that showed up in ppc64le and s390x Ruby has been between 5 and 10 every year, so I assume the same pace for my obligation as a maintainer.

Updated by jaruga (Jun Aruga) 3 days ago

Thank you, Rei Odaira. I appreciate your work.

I can work to send a pull-request to add ppc64le and s390x cases to (Travis) CI.
However it's up to you. Feel free to take the task.

Updated by jaruga (Jun Aruga) 3 days ago

I found someone's pull-request adding s390x in Travis CI, and the result (Travis) is succeeded. Someone could you check and merge this?

Adding s390x support for Travis build
https://github.com/ruby/ruby/pull/2727

Updated by jaruga (Jun Aruga) 3 days ago

As I faced stack level too deep (SystemStackError) in socket.rb:897 in ip_address_list on only the Travis ppc64le environment, I am debugging it with strace command on my forked repository enabling Travis ppc64le here.

https://github.com/junaruga/ruby/commits/feature/ppc64le
https://travis-ci.org/junaruga/ruby/builds/621767234

$ $SETARCH make -s test-spec MSPECOPT=-ff
...
<Thread:0x000009432a9792f0@/home/travis/build/junaruga/ruby/spec/mspec/lib/mspec/matchers/block_caller.rb:3 run> terminated with exception (report_on_exception is true):
/home/travis/build/junaruga/ruby/build/.ext/common/socket.rb:897:in `ip_address_list': stack level too deep (SystemStackError)
  from /home/travis/build/junaruga/ruby/build/.ext/common/socket.rb:897:in `udp_server_sockets'
  from /home/travis/build/junaruga/ruby/build/.ext/common/socket.rb:1027:in `udp_server_loop'
  from /home/travis/build/junaruga/ruby/spec/ruby/library/socket/socket/udp_server_loop_spec.rb:7:in `block (4 levels) in <top (required)>'
  from /home/travis/build/junaruga/ruby/spec/mspec/lib/mspec/matchers/block_caller.rb:4:in `block in matches?'

#<Thread:0x000009432a971a00@/home/travis/build/junaruga/ruby/spec/ruby/library/socket/socket/udp_server_loop_spec.rb:24 run> terminated with exception (report_on_exception is true):
/home/travis/build/junaruga/ruby/build/.ext/common/socket.rb:897:in `ip_address_list': stack level too deep (SystemStackError)
  from /home/travis/build/junaruga/ruby/build/.ext/common/socket.rb:897:in `udp_server_sockets'
  from /home/travis/build/junaruga/ruby/spec/ruby/library/socket/fixtures/classes.rb:149:in `udp_server_sockets'
  from /home/travis/build/junaruga/ruby/build/.ext/common/socket.rb:1027:in `udp_server_loop'
  from /home/travis/build/junaruga/ruby/spec/ruby/library/socket/socket/udp_server_loop_spec.rb:25:in `block (4 levels) in <top (required)>'

getsockname's pid=-1334654655 looks weird at https://travis-ci.org/junaruga/ruby/jobs/621767236#L16525

$ strace -f $SETARCH make -s test-spec MSPECOPT=-ff SPECOPTS="../spec/ruby/library/socket/socket/udp_server_loop_spec.rb"
...
[pid 17414] <... getsockname resumed> {sa_family=AF_NETLINK, pid=-1334654655, groups=00000000}, [12]) = 0
[pid 17413] <... read resumed> 0x7ffffec81540, 8) = -1 EAGAIN (Resource temporarily unavailable)
[pid 17414] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7fb4e1ded7c0} ---
..

Could you help it?
Thank you.

Also available in: Atom PDF