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
Possibly memory leak when matching strings using pre-compiled regexes stored in hash key (perl >= v5.26) #16427
Comments
From @rootkwokHello guys, I have a long running perl script which allows the user configure the %action = ( qr/^regex here/ => sub { print "match" }, ); I have written a small test for this problem, you can find it in the |-- 20180221-mem-leak-poc.pl According to my empirical result, this problem occurs when using perl newer
This is perl 5, version 26, subversion 1 (v5.26.1) built for
I have traced the problem a little bit and I *guess* the problem is in the � |
From @rootkwok |
From @shlomifOn Wed, 21 Feb 2018 07:49:20 -0800
Hi all! I reworked the example code to remove some potential problems, and verified #!/usr/bin/perl use strict; # my print "== Test result on my %h = ( my @list = qw/ abcd abcd efgh ijkl mnop qrst uvwx /; while (1) { print ">>> Count mismatch for $name\n" if ( $c != $expected );
|
The RT System itself - Status changed from 'new' to 'open' |
From @dur-randirBisect points to commit b10cb25 regcomp.c: S_concat_pat: guard against missing trailing nulls The regex engine expects the pattern to have a null byte at |
From @demerphqOn 22 Feb 2018 12:39, "via RT" <perlbug-followup@perl.org> wrote: # New Ticket Created by Hello guys, I have a long running perl script which allows the user configure the %action = ( qr/^regex here/ => sub { print "match" }, ); Regardless if the bug, perl hash keys are strings not objects. Perl will Yves I have written a small test for this problem, you can find it in the |-- 20180221-mem-leak-poc.pl According to my empirical result, this problem occurs when using perl newer
This is perl 5, version 26, subversion 1 (v5.26.1) built for
I have traced the problem a little bit and I *guess* the problem is in the � |
From @demerphqOn 22 February 2018 at 12:29, Sergey Aleynikov via RT
Thanks, I forgot an sv_2mortal in that patch, I will push a fix soon. Much obliged for the bisect! Yves -- |
From @demerphqOn 23 February 2018 at 04:27, demerphq <demerphq@gmail.com> wrote:
Fixed in 910a6a8 Unfortunately I don't know how to test for a memory leak, so no tests included. Yves -- |
From @iabynOn Fri, Feb 23, 2018 at 10:34:50AM +0100, demerphq wrote:
see t/op/svleak.t. It runs a bit of code several times in a loop and -- |
From @demerphqOn 23 February 2018 at 14:03, Dave Mitchell <davem@iabyn.com> wrote:
Thanks, i just pushed 06f26dc which FWIW, there is still an open question why this happens at all. Keys Yves -- |
From @demerphqOn 25 February 2018 at 10:50, demerphq <demerphq@gmail.com> wrote:
Apparently I am wrong: $ ./perl -Ilib -MDevel::Peek -le'%h=("^foo"=>1); my ($re)=keys %h; Dump $re' This appears to be a side-effect of shared keys. Another good reason not to put patterns in keys. :-( Yves -- |
From @dur-randirOn Fri, 23 Feb 2018 01:35:02 -0800, demerphq wrote:
Since this is a regression in 5.26, should it also be added to voting list for the future 5.26.2? Or there're no plans for it? |
From @demerphqOn 25 February 2018 at 11:00, Sergey Aleynikov via RT
Sure. I don't remember how to do that tho. Where does the voting list Yves -- |
From @demerphqOn 25 February 2018 at 10:57, demerphq <demerphq@gmail.com> wrote:
Corroborating this I hacked a way to get an unshared hash, and then $ ./perl -Ilib -MHash::Util=new_unshared_hash -MDevel::Peek -e'my Yves -- |
From @dur-randirOn Sun, 25 Feb 2018 01:58:15 -0800, demerphq wrote:
But the failed check in regcomp.c is not *(SvEND(msv)) == 0, but rather SvLEN(msv) > SvCUR(msv). But doesn't line 3134 in hv.c (HEK_KEY(hek)[len] = 0;) guarantee that it's implicitly null-terminated, just not shown by Devel::Peek as such? |
From @dur-randirOn Sun, 25 Feb 2018 02:13:12 -0800, demerphq wrote:
Looks like votes-5.26.xml in a maint-votes branch. |
From @demerphqOn 25 February 2018 at 11:19, Sergey Aleynikov via RT
That sounds correct, but i dont think the regex engine has any way to Yves -- |
From @dur-randirOn Sun, 25 Feb 2018 02:57:09 -0800, demerphq wrote:
But you can check for SvIsCOW_shared_hash, which guarantees it to be from sharepvn. |
From @xsawyerxOn 02/25/2018 12:13 PM, demerphq wrote:
It should be, yes!
The branch "maint-votes" in git. I've added them here: https://perl5.git.perl.org/perl.git/commitdiff/5f21d69b722f6a73f185e533ecf138e17adeabce With a vote from both of us, Yves. |
From @demerphqOn 25 February 2018 at 16:21, Sawyer X <xsawyerx@gmail.com> wrote:
Thanks, I was busy trying to test Sergey Aleynikov's suggestion of Yves -- |
From @demerphqOn 25 February 2018 at 12:03, Sergey Aleynikov via RT
Thanks again for your help, i have pushed a patch to implement this suggestion: cheers, -- |
From @xsawyerxOn 02/25/2018 05:26 PM, demerphq wrote:
I think separate patches are better. It will align with blead. |
What's the status of this bug? |
Looks to me like it can be closed. Closing. |
Migrated from rt.perl.org#132892 (status was 'open')
Searchable as RT132892$
The text was updated successfully, but these errors were encountered: