Description of problem: I'm trying to build the perl-Coro package for EPEL 9 in my COPR; apart from missing a dependency (which can be provided easily enough), it fails its own tests in Coro::Event by blocking forever in Event/t/01_unblock.t, which I've able to track down to a do_timer() -> Coro::schedule call, inside of which it's just sitting there forever in pselect() call that keeps timing out with no events, as strace shows. When I skip only the Coro::Event-specific problematic tests, all other tests pass. This is only happening in the EL9 environment. Using mock on a Fedora 38 host, the same machine builds the exact same source package just fine on el8, f38, and f39 with all tests passing, but freezes invariably on el9. My COPR (jafd/perl-modules) logs show that it freezes in the same place independently of architecture, as I build there for aarch64 and x86_64, thus pointing at some kind of EL9-specific userspace problem. (https://download.copr.fedorainfracloud.org/results/jafd/perl-modules/epel-9-x86_64/06080268-perl-Coro/builder-live.log.gz) I'm wondering if it's something the maintainers have run into already and thus stopped building perl-Coro for EPEL 9. I'd like to help however I can to fix this — if I knew how. I've tried downgrading perl-Event to 1.27, the same version EL8 has, and it doesn't help.
FWIW, the package's tests pass fine on Fedora 33, which used to ship the same Perl version as EL9 (5.32).
Those are open files of the hanged process: # lsof -p 14525 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME perl 14525 test cwd DIR 253,1 4096 126876 /home/test/fedora/perl-Coro/Coro-6.57 perl 14525 test rtd DIR 253,1 4096 2 / perl 14525 test txt REG 253,1 15496 17699 /usr/bin/perl perl 14525 test mem REG 253,1 106070960 17578 /usr/lib/locale/locale-archive perl 14525 test mem REG 253,1 2387016 29676 /usr/lib64/libc.so.6 perl 14525 test mem REG 253,1 3724888 17887 /usr/lib64/libperl.so.5.32.1 perl 14525 test mem REG 253,1 103568 144768 /home/test/fedora/perl-Coro/Coro-6.57/blib/arch/auto/Coro/EV/EV.so perl 14525 test mem REG 253,1 169984 257399 /usr/lib64/perl5/vendor_perl/auto/EV/EV.so perl 14525 test mem REG 253,1 61360 269248 /usr/lib64/perl5/vendor_perl/auto/List/Util/Util.so perl 14525 test mem REG 253,1 48872 269167 /usr/lib64/perl5/vendor_perl/auto/Socket/Socket.so perl 14525 test mem REG 253,1 78336 144757 /home/test/fedora/perl-Coro/Coro-6.57/blib/arch/auto/Coro/Event/Event.so perl 14525 test mem REG 253,1 36520 254101 /usr/lib64/perl5/vendor_perl/auto/Time/HiRes/HiRes.so perl 14525 test mem REG 253,1 100320 258847 /usr/lib64/perl5/vendor_perl/auto/Event/Event.so perl 14525 test mem REG 253,1 475920 144727 /home/test/fedora/perl-Coro/Coro-6.57/blib/arch/auto/Coro/State/State.so perl 14525 test mem REG 253,1 16016 276089 /usr/lib64/perl5/vendor_perl/auto/Guard/Guard.so perl 14525 test mem REG 253,1 201808 4248 /usr/lib64/libcrypt.so.2.0.0 perl 14525 test mem REG 253,1 904680 29677 /usr/lib64/libm.so.6 perl 14525 test mem REG 253,1 26988 1501 /usr/lib64/gconv/gconv-modules.cache perl 14525 test mem REG 253,1 841768 7550 /usr/lib64/ld-linux-x86-64.so.2 perl 14525 test mem REG 253,1 3284 126692 /usr/lib/locale/en_US.utf8/LC_TIME perl 14525 test 0u CHR 136,2 0t0 5 /dev/pts/2 perl 14525 test 1u CHR 136,2 0t0 5 /dev/pts/2 perl 14525 test 2u CHR 136,2 0t0 5 /dev/pts/2 perl 14525 test 3u unix 0xffff9cc2c38250c0 0t0 34290 type=STREAM (CONNECTED) perl 14525 test 4u unix 0xffff9cc2c3824400 0t0 34291 type=STREAM (CONNECTED) perl 14525 test 5u a_inode 0,14 0 45 [eventpoll:3,6] perl 14525 test 6u a_inode 0,14 0 45 [eventfd:6] There are no other processes it communicates to, so that files are the complete user space. Another clue is that perl-Coro compiles in code packaged in libev-source. Who knows where everywhere the code is compiled in. Theoretically all packages like that should "Provides: bundled(libev)". But even perl-Coro breaks this rule. Worrisome is that libev-source comes from libev-epel-4.33-5.el9 source package. That means its a duplication of RHEL libev-4.33-5.el9 package. Maybe the sources went out of synchronization.
The libev-source is compiled in the perl-EV package by the same author (perl-Coro doesn't depend on libev directly, as far as my eyes and ripgrep can tell). Both the bundled sources, perl-EV, and the libev-source package are at version 4.33, with relevant .c and .h files being identical. I do agree though that it amounts to a fine mess. Wouldn't a better approach be that libev should have both itself and the corresponding perl-EV tarball as its sources so they are guaranteed to be built from the same thing in sync (or at least compatible enough, should a need for a fix from upstream arise for either)? Something like ImageMagick and PerlMagick (although those indeed are being built from the same source). Still, the hanging process is stuck when working with Event and not EV/libev, so this may just as well be red herring (for this particular bug, EV/libev packaging issues notwithstanding). Thanks for the pointers anyway!
On still another hand: at the moment it hangs, gdb says that the backtrace looks like this: #0 0x00007fdccb14ea7a in epoll_wait () from target:/lib64/libc.so.6 #1 0x00007fdccb2b86b5 in epoll_poll.lto_priv () from target:/usr/lib64/perl5/vendor_perl/auto/EV/EV.so #2 0x00007fdccb2bb3dd in ev_run.lto_priv () from target:/usr/lib64/perl5/vendor_perl/auto/EV/EV.so #3 0x00007fdccb2a9169 in XS_Coro__EV__loop_oneshot (my_perl=<optimized out>, cv=0x561778ed5df8) at /builddir/build/BUILD/Coro-6.57/EV/EV.xs:397 So now I'm confused if there is not some kind of clash where it's supposed to be using Event, but is using EV/libev instead.
There's been no movement on this bug for 6 months now so I feel comfortable closing it. Yaroslav, I invite you to contact upstream if you feel there is a bug in the code.