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

epoll #550

Closed
AlexDaniel opened this issue Feb 8, 2019 · 5 comments
Closed

epoll #550

AlexDaniel opened this issue Feb 8, 2019 · 5 comments
Assignees
Labels
issue sent Posted a previously unreported issue with the original author to investigate

Comments

@AlexDaniel
Copy link
Member

Module epoll cannot be installed (AlwaysFail), perhaps it has some failing tests.

  • Tickets are opened/closed in this repo automatically (though not immediately).
  • If you can install the module without any problems, add works for me label, leave a comment saying that it works for you and mention any details that you feel are important.
  • If it needs a native library, put native dependency label, describe what you did to install it and ensure that same instructions are present in the README file of the module (otherwise submit a pull request). Also try to update this wiki page.
  • If the module is broken, try to fix it and send a PR. Add PR sent label.
  • If there is a problem in one of the dependencies, add failing dependency label and write a comment explaining the situation. Feel free to work on the corresponding ticket for the failing dependency.
  • It is a good idea to assign yourself to this ticket if you're working on it (to make sure two or more people are not working on the same ticket at the same time).
  • Once you are done, search for a next ticket.

If you can't self-assign yourself or attach a label, please let us know on #perl6 channel on freenode or just leave a comment here. We will try to give you privileges as fast as possible.

Output:

===> Searching for: epoll
===> Found: epoll:ver<0.2> [via Zef::Repository::Ecosystems<cpan>]
===> Fetching [OK]: epoll:ver<0.2> to /home/alex/Blin/data/zef-data/tmp/1549582494.2026.7922/epoll-0.2.tar.gz
===> Extraction [OK]: epoll to /home/alex/Blin/data/zef-data/store/epoll-0.2.tar.gz
===> Testing: epoll:ver<0.2>
t/00-meta.t ...... ok
# Failed test 'No events'
# at t/01-simple.t line 36
# expected: ''
#      got: 'epoll-event<140219946315344>'
# Looks like you failed 1 test of 6
t/01-simple.t .... 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/6 subtests 
t/02-multiple.t .. ok

Test Summary Report
-------------------
t/01-simple.t  (Wstat: 256 Tests: 6 Failed: 1)
  Failed test:  6
  Non-zero exit status: 1
Files=3, Tests=17,  9 wallclock secs ( 0.04 usr  0.00 sys +  7.07 cusr  0.36 csys =  7.47 CPU)
Result: FAIL
===> Testing [FAIL]: epoll:ver<0.2>
Failed to get passing tests, but continuing with --force-test
===> Installing: epoll:ver<0.2>
===> Install [OK] for epoll:ver<0.2>

Ping @CurtTilmes

@JJ JJ self-assigned this Feb 8, 2019
@JJ JJ added the works for me Does not seem to be any problem label Feb 8, 2019
@JJ
Copy link
Collaborator

JJ commented Feb 8, 2019

Maybe it's a Flapper? Again, works for me...

@AlexDaniel AlexDaniel added issue sent Posted a previously unreported issue with the original author to investigate and removed works for me Does not seem to be any problem labels Feb 8, 2019
@AlexDaniel
Copy link
Member Author

Yeah, it is. I reported it here but it is ignored: CurtTilmes/perl6-epoll#2 (comment)

@CurtTilmes
Copy link

Never mind. The previous report was for a different test. I'll mark even the simple test as extended so it won't get run during install. It isn't a problem with the module, just the test -- it is trying to set up multiple threads to communicate within a single process. It works fine monitoring external processes -- just need a more complicated test scheme.

@CurtTilmes
Copy link

This is a different issue from the old one (CurtTilmes/perl6-epoll#2 t/02-multiple.t is flapping). That test was more complicated, and could occasionally fail. After the last report I marked that test as extended, and indeed it didn't fail this time. The previous report was not ignored.

This report is that even the 01-simple.t is failing? I've never seen that fail before in any runs. It starts up a single process, sends a single string, sees the event, does a slurp(:close) to make sure there are no more events coming on the process, then verifies that there are no events reported. If it is reporting the process as readable after the slurp(:close) something is really wrong, not just a bad test. It is difficult for me to debug because it always does the right thing on my host and on travis. I'll have to get more details on the system, os, rakudo, etc. to try to replicate.

@AlexDaniel
Copy link
Member Author

@CurtTilmes it's a 24 core google compute instance running with 100% CPU utilization.

@AlexDaniel AlexDaniel mentioned this issue Feb 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue sent Posted a previously unreported issue with the original author to investigate
Projects
None yet
Development

No branches or pull requests

3 participants