Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests failing on s390x #15

Open
lucaskanashiro opened this issue Mar 4, 2021 · 2 comments
Open

Tests failing on s390x #15

lucaskanashiro opened this issue Mar 4, 2021 · 2 comments

Comments

@lucaskanashiro
Copy link

The following tests are failing in Debian and Ubuntu infrastructure on s390x architecture:

Failures:

  1) HttpParser::Parser#initialize the error should be inspectable
     Failure/Error: expect(@inst.error).to be_kind_of(::HttpParser::Error::INVALID_METHOD)
       expected #<HttpParser::Error::UNKNOWN: an unknown error occurred (UNKNOWN)> to be a kind of HttpParser::Error::INVALID_METHOD
     # ./spec/error_spec.rb:20:in `block (2 levels) in <top (required)>'

  2) HttpParser::Parser#initialize raises different error types depending on the error
     Failure/Error: expect(@inst.error).to be_kind_of(::HttpParser::Error::INVALID_VERSION)
       expected #<HttpParser::Error::INVALID_CONSTANT: invalid constant string (INVALID_CONSTANT)> to be a kind of HttpParser::Error::INVALID_VERSION
     # ./spec/error_spec.rb:26:in `block (2 levels) in <top (required)>'

  3) HttpParser::Instance#initialize #type should default to :both
     Failure/Error: expect(subject.type).to eq(:both)
     
       expected: :both
            got: :request
     
       (compared using ==)
     
       Diff:
       @@ -1 +1 @@
       -:both
       +:request
       
     # ./spec/instance_spec.rb:24:in `block (3 levels) in <top (required)>'

  4) HttpParser::Parser#initialize #upgrade? should return true if the Upgrade header was set
     Failure/Error: expect(@inst.upgrade?).to eq(true)
     
       expected: true
            got: false
     
       (compared using ==)
     
       Diff:
       @@ -1 +1 @@
       -true
       +false
       
     # ./spec/parser_spec.rb:270:in `block (3 levels) in <top (required)>'

Finished in 0.01765 seconds (files took 0.08681 seconds to load)
34 examples, 4 failures

Failed examples:

rspec ./spec/error_spec.rb:18 # HttpParser::Parser#initialize the error should be inspectable
rspec ./spec/error_spec.rb:24 # HttpParser::Parser#initialize raises different error types depending on the error
rspec ./spec/instance_spec.rb:23 # HttpParser::Instance#initialize #type should default to :both
rspec ./spec/parser_spec.rb:269 # HttpParser::Parser#initialize #upgrade? should return true if the Upgrade header was set

Full logs:

https://buildd.debian.org/status/fetch.php?pkg=ruby-http-parser&arch=s390x&ver=1.2.1-4&stamp=1604434045&raw=0
https://launchpadlibrarian.net/526217639/buildlog_ubuntu-hirsute-s390x.ruby-http-parser_1.2.1-4_BUILDING.txt.gz

FWIW I ran the tests from the current master branch in a s390x VM and I got the same failures.

@utkarsh2102
Copy link

/cc: @makeable, @stakach: could you perhaps take a look at this?

I don't expect a different behavior on s390x architecture, for example, HttpParser::Instance#initialize #type should indeed default to :both and probably not :request. Likewise, I don't understand why it'd return false if the "Upgrade header" is already set.

For other architectures, this works fine, maybe we're missing something on s390x? or is there something wrong with tests in general sense, maybe(!?), 'cause I don't see an obvious reason for them to fail here?

Thanks in advance! 🙈

@utkarsh2102
Copy link

Oh well, I hope the problem isn't due to native extensions on s390x. I've seen sometimes those to be a problem, but hoping this wouldn't be it here as well (or is it!?) 🙈

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants