Skip Menu |

This queue is for tickets about the Linux-Epoll CPAN distribution.

Report information
The Basics
Id: 127127
Status: resolved
Priority: 0/
Queue: Linux-Epoll

People
Owner: Nobody in particular
Requestors: leonerd-cpan [...] leonerd.org.uk
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.015
Fixed in:
  • 0.013
  • 0.016



Subject: Upsets die() handling during callbacks
I've yet to narrow it down, but Linux::Epoll 0.015 has caused a change in behaviour of a unit test in Net::Async::HTTP. In summary: NaHTTP's test fails with the Epoll loop when using Linux::Epoll 0.015, but passes on 0.013, or when using other non-epoll loops. More background in https://rt.cpan.org/Ticket/Display.html?id=127126 I shall try to isolate a self-contained test case. -- Paul Evans
Update: Also fails in 0.014, so it's something in this diff that upsets it: https://metacpan.org/diff/file?target=LEONT/Linux-Epoll-0.014/&source=LEONT%2FLinux-Epoll-0.013 I suspect probably the added G_EVAL flag to the main call_sv() in wait(). I've encountered similarly bizarre situations in my work with Future::AsyncAwait - I wonder if you'll have to wrap a JMPENV_PUSH/JMPENV_POP pair around this one? -- Paul Evans
In addition, versions 0.014 and 0.015 seem to cause another of my test files to SEGV about half of the time: $ ./Build && prove -b t/80cross-http.t Building Net-Async-HTTP t/80cross-http.t .. ok All tests successful. Files=1, Tests=3, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.14 cusr 0.01 csys = 0.17 CPU) Result: PASS leo@shy:~/src/perl/Net-Async-HTTP [bzr] $ ./Build && prove -b t/80cross-http.t Building Net-Async-HTTP t/80cross-http.t .. All 3 subtests passed Test Summary Report ------------------- t/80cross-http.t (Wstat: 11 Tests: 3 Failed: 0) Non-zero wait status: 11 Files=1, Tests=3, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.14 cusr 0.00 csys = 0.16 CPU) Result: FAIL whereas these tests pass reliably with 0.013 or non-epoll loops. For a failure case: $ gdb --args perl -Mblib t/80cross-http.t GNU gdb (Debian 8.1-4) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. ... (gdb) run Starting program: /usr/bin/perl -Mblib t/80cross-http.t [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". ok 1 - $response->code ok 2 - $response->content_type ok 3 - $response->content 1..3 Program received signal SIGSEGV, Segmentation fault. 0x00005555556280aa in Perl_av_delete (my_perl=0x555555756260, av=0x0, key=10, flags=flags@entry=4) at av.c:900 900 av.c: No such file or directory. (gdb) bt #0 0x00005555556280aa in Perl_av_delete (my_perl=0x555555756260, av=0x0, key=10, flags=flags@entry=4) at av.c:900 #1 0x00007ffff7f9c759 in weak_set (my_perl=<optimized out>, sv=<optimized out>, magic=<optimized out>) at lib/Linux/Epoll.xs:160 #2 0x000055555560fc56 in Perl_mg_set (my_perl=my_perl@entry=0x555555756260, sv=sv@entry=0x555556a0c100) at mg.c:296 #3 0x000055555564bc05 in Perl_sv_kill_backrefs (my_perl=0x555555756260, sv=0x555556b42d90, av=<optimized out>) at sv.c:6272 #4 0x00005555556139dd in Perl_magic_killbackrefs (my_perl=<optimized out>, sv=<optimized out>, mg=<optimized out>) at mg.c:2436 #5 0x0000555555636d80 in S_sv_unmagicext_flags (my_perl=0x555555756260, sv=0x555556b42d90, type=60, vtbl=0x0, flags=0) at sv.c:5892 #6 0x0000555555635e9e in Perl_sv_clear (my_perl=my_perl@entry=0x555555756260, orig_sv=orig_sv@entry=0x555556b43288) at sv.c:6588 #7 0x0000555555636681 in Perl_sv_free2 (my_perl=my_perl@entry=0x555555756260, sv=0x555556b43288, rc=<optimized out>) at sv.c:7073 #8 0x00005555555dadf0 in S_SvREFCNT_dec_NN (sv=<optimized out>, my_perl=0x555555756260) at inline.h:200 #9 Perl_cv_undef_flags (my_perl=my_perl@entry=0x555555756260, cv=cv@entry=0x555556b43258, flags=flags@entry=0) at pad.c:436 #10 0x00005555555db027 in Perl_cv_undef (my_perl=my_perl@entry=0x555555756260, cv=cv@entry=0x555556b43258) at pad.c:289 #11 0x0000555555635edb in Perl_sv_clear (my_perl=my_perl@entry=0x555555756260, orig_sv=orig_sv@entry=0x555556b43258) at sv.c:6623 #12 0x0000555555636681 in Perl_sv_free2 (my_perl=my_perl@entry=0x555555756260, sv=0x555556b43258, rc=<optimized out>) at sv.c:7073 #13 0x000055555560f788 in S_SvREFCNT_dec (sv=<optimized out>, my_perl=0x555555756260) at inline.h:189 #14 S_mg_free_struct (my_perl=my_perl@entry=0x555555756260, sv=sv@entry=0x555556a0c100, mg=0x555556b51350) at mg.c:566 #15 0x000055555561020e in Perl_mg_free (my_perl=my_perl@entry=0x555555756260, sv=sv@entry=0x555556a0c100) at mg.c:588 #16 0x0000555555635ea9 in Perl_sv_clear (my_perl=my_perl@entry=0x555555756260, orig_sv=orig_sv@entry=0x555555783ab0) at sv.c:6589 #17 0x0000555555636681 in Perl_sv_free2 (my_perl=my_perl@entry=0x555555756260, sv=0x555555783ab0, rc=<optimized out>) at sv.c:7073 #18 0x000055555560f788 in S_SvREFCNT_dec (sv=<optimized out>, my_perl=0x555555756260) at inline.h:189 #19 S_mg_free_struct (my_perl=my_perl@entry=0x555555756260, sv=sv@entry=0x5555557833f0, mg=0x55555649f860) at mg.c:566 #20 0x000055555561020e in Perl_mg_free (my_perl=my_perl@entry=0x555555756260, sv=sv@entry=0x5555557833f0) at mg.c:588 #21 0x0000555555635ea9 in Perl_sv_clear (my_perl=my_perl@entry=0x555555756260, orig_sv=orig_sv@entry=0x555556683860) at sv.c:6589 #22 0x0000555555636681 in Perl_sv_free2 (my_perl=0x555555756260, sv=0x555556683860, rc=<optimized out>) at sv.c:7073 #23 0x0000555555653f75 in Perl_pp_undef (my_perl=0x555555756260) at pp.c:965 #24 0x0000555555628676 in Perl_runops_standard (my_perl=0x555555756260) at run.c:42 #25 0x00005555555a0222 in Perl_call_sv (my_perl=my_perl@entry=0x555555756260, sv=sv@entry=0x555555788ac8, flags=flags@entry=13) at perl.c:2856 #26 0x00005555555a2874 in Perl_call_list (my_perl=my_perl@entry=0x555555756260, oldscope=1, paramList=0x55555597c240) at perl.c:5082 #27 0x00005555555a435f in perl_destruct (my_perl=0x555555756260) at perl.c:618 #28 0x000055555557f31c in main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at perlmain.c:134 Unfortunately, while it crashes about half the time when run under regular `perl`, I was unable to get a single SEGV in over 50 attempts to run it under `debugperl`; so I suspect whatever is causing it to fail may be somehow related to uninitialised memory which -DDEBUGGING somehow interacts with. -- Paul Evans
Subject: Re: [rt.cpan.org #127127] Upsets die() handling during callbacks
Date: Mon, 17 Sep 2018 23:44:37 +0200
To: bug-Linux-Epoll [...] rt.cpan.org
From: Leon Timmermans <fawaka [...] gmail.com>
On Mon, Sep 17, 2018 at 4:11 PM Paul Evans via RT <bug-Linux-Epoll@rt.cpan.org> wrote: Show quoted text
> > Mon Sep 17 10:11:06 2018: Request 127127 was acted upon. > Transaction: Ticket created by PEVANS > Queue: Linux-Epoll > Subject: Upsets die() handling during callbacks > Broken in: 0.015 > Severity: (no value) > Owner: Nobody > Requestors: leonerd-cpan@leonerd.org.uk > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=127127 > > > > I've yet to narrow it down, but Linux::Epoll 0.015 has caused a change in behaviour of a unit test in Net::Async::HTTP. In summary: NaHTTP's test fails with the Epoll loop when using Linux::Epoll 0.015, but passes on 0.013, or when using other non-epoll loops. > > More background in > > https://rt.cpan.org/Ticket/Display.html?id=127126 > > I shall try to isolate a self-contained test case.
This should be solved in 0.016 Leon
Yup; tests reliably pass again with 0.016 -- Paul Evans