Bug #86910 for forks: Use of each() on hash after insertion without resetting hash iterator

Sat Jul 13 13:19:18 2013 piotr.roszatycki [...] gmail.com - Ticket created

Subject:

Use of each() on hash after insertion without resetting hash iterator

Use of each() on hash after insertion without resetting hash iterator results in undefined behavior at /home/dexter/perl5/perlbrew/perls/perl-blead/lib/site_perl/5.19.2/x86_64-linux/forks.pm line 1736.

Thu Dec 05 11:37:54 2013 gbjk [...] thermeon.com - Correspondence added

We've also encountered this. I propose the attached patch. I note that there's been no reply from the current maintainer. I've emailed him to see if he's maintaining this module. If he isn't, I'll seek co-maint to fix this.

Subject:

forks.patch

diff -Naur forks-0.34.orig/lib/forks/Devel/Symdump.pm forks-0.34/lib/forks/Devel/Symdump.pm --- forks-0.34.orig/lib/forks/Devel/Symdump.pm 2013-12-05 16:07:34.558662688 +0000 +++ forks-0.34/lib/forks/Devel/Symdump.pm 2013-12-05 16:17:13.054170779 +0000 @@ -51,7 +51,8 @@ my $result = {}; foreach $pack (@packages){ no strict; - while (($key,$val) = each(%{*{"$pack\::"}})) { + foreach my $key (keys %{"${pack}::"}) { + my $value = ${"${pack}::"}{$key}; my $gotone = 0; #### perl 5.10.x special case: SCALAR? ####

Thu Dec 05 11:37:55 2013 The RT System itself - Status changed from 'new' to 'open'

Sun Dec 08 06:15:25 2013 RYBSKEJ [...] cpan.org - Correspondence added

This is the same as https://rt.cpan.org/Public/Bug/Display.html?id=87886 Please propose patch to the original Devel::Symdump module and I will shadow the final accepted change by that module's author here.

Sat Feb 08 00:40:30 2014 ether [...] cpan.org - Correspondence added

On 2013-07-13 10:19:18, DEXTER wrote: Show quoted text

> Use of each() on hash after insertion without resetting hash iterator > results in undefined behavior at > /home/dexter/perl5/perlbrew/perls/perl- > blead/lib/site_perl/5.19.2/x86_64-linux/forks.pm line 1736.

What were you doing when you got this error? Can you reproduce it?

Sat Feb 08 00:40:48 2014 ether [...] cpan.org - Reference by ticket #87886 added

Thu Apr 10 03:56:03 2014 ailin [...] devio.us - Correspondence added

Subject:	[rt.cpan.org #86910]
Date:	Thu, 10 Apr 2014 09:55:43 +0200
To:	bug-forks [...] rt.cpan.org
From:	"A.N." <ailin [...] devio.us>

These are 2 different bugs. After updating system Perl we are now too affected by this issue. The following sample script usually reproduces the issue 2-3 times on SuSE/Perl 5.18.1 use strict; use warnings; use forks; use Thread::Queue; use Time::HiRes; my $q = Thread::Queue->new; my $worker = async { while (my $item = $q->dequeue) { print "$item\n"; sleep .1; } }; for (1..100) { $q->enqueue(":E$_"); sleep .1; sleep .4 unless $_%3; } $q->enqueue(undef); $worker->join; Error is: Use of each() on hash after insertion without resetting hash iterator results in undefined behavior, Perl interpreter: 0xb35010 at forks.pm line 1736. This is not the Symdump error.

Thu Apr 10 04:57:33 2014 ailin [...] devio.us - Correspondence added

Subject:	Re: [rt.cpan.org #86910]
Date:	Thu, 10 Apr 2014 10:57:16 +0200
To:	bug-forks [...] rt.cpan.org
From:	"A.N." <ailin [...] devio.us>

by the way, make test also shows the warning here[1]. One solution might be switch to a for (keys ) loop at the expense of speed/memory, see patch. Otherwise writing to any hash variables must be strictly avoided if this Perl issue isn't fixed. It might be wise to check the code for more undefined behaviour due to each failures, which it looks like there would be. [1] http://www.cpantesters.org/cpan/report/8975ffb6-bcda-11e3-9409-6628fffb7322

Message body is not shown because sender requested not to inline it.

Wed Jun 25 22:19:44 2014 RYBSKEJ [...] cpan.org - Correspondence added

On Thu Apr 10 04:57:33 2014, ailin@devio.us wrote: Show quoted text

> by the way, make test also shows the warning here[1]. One solution > might > be switch to a for (keys ) loop at the expense of speed/memory, see > patch. Otherwise writing to any hash variables must be strictly > avoided > if this Perl issue isn't fixed. It might be wise to check the code for > more undefined behaviour due to each failures, which it looks like > there > would be. > > [1] http://www.cpantesters.org/cpan/report/8975ffb6-bcda-11e3-9409- > 6628fffb7322

Fixed in 0.35 release.

Wed Jun 25 22:19:45 2014 RYBSKEJ [...] cpan.org - Status changed from 'open' to 'resolved'

Wed Jun 25 22:19:46 2014 RYBSKEJ [...] cpan.org - Taken

Wed Jun 25 22:19:46 2014 RYBSKEJ [...] cpan.org - Fixed in 0.35 added