Skip Menu |

This queue is for tickets about the List-MoreUtils CPAN distribution.

Report information
The Basics
Id: 110998
Status: rejected
Priority: 0/
Queue: List-MoreUtils

People
Owner: Nobody in particular
Requestors: stro [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in:
  • 0.22
  • 0.23
  • 0.23_01
  • 0.24
  • 0.25_01
  • 0.25_02
  • 0.26
  • 0.27_01
  • 0.27_02
  • 0.27_03
  • 0.27_04
  • 0.28
  • 0.29
  • 0.30
  • 0.31_01
  • 0.31_02
  • 0.32
  • 0.33
  • 0.33_005
  • 0.33_007
  • 0.400_001
  • 0.400_002
  • 0.400_003
  • 0.400_004
  • 0.400_005
  • 0.400_006
  • 0.400_007
  • 0.400_008
  • 0.400_009
  • 0.400_010
  • 0.401
  • 0.402
  • 0.403
  • 0.404
  • 0.405
  • 0.406
  • 0.407
  • 0.408
  • 0.409_001
  • 0.409_002
  • 0.409_003
  • 0.410
  • 0.411_001
  • 0.412
  • 0.413
Fixed in: (no value)



Subject: XS implementation of pairwise fails with memory allocation error when there are more return values than in original lists
Hey guys, %subj. Pretty much every call like pairwise { ($a) x $b } @list1, @list2 has the problem. Attached script listmoreutils-memory.pl can be used to reproduce it. From what I understand by looking at the code, only a maximum of lists elements are expected to return, which is not always the case. Interesting that sometimes it works and it's based on the number of elements in arrays, see listmoreutils-ok.pl as an example. Changing the number of elements in the first array produces a vast variety of error messages: Segmentation fault: 11 perl(90433,0x7fff71397300) malloc: *** error for object 0x7ff098f09bc8: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Abort trap: 6 Bizarre copy of ARRAY in list assignment at ./listmoreutils-memory-arr.pl line 12. Use of uninitialized value in freed op during global destruction. Use of uninitialized value in freed op during global destruction. Use of uninitialized value in freed op during global destruction. Use of uninitialized value in freed op during global destruction. Use of uninitialized value in freed op during global destruction. Use of uninitialized value in freed op during global destruction. Sometimes it just works. -- S. T.
Subject: listmoreutils-memory.pl
#!/usr/bin/perl -w use strict; use warnings; use List::MoreUtils qw/ pairwise /; my @ids = (1, 2, 3); my @quantities = [map { 42 } @ids]; my @id_stream = pairwise { (our $a) x our $b } @ids, @quantities; print join(', ', @id_stream);
Subject: listmoreutils-ok.pl
#!/usr/bin/perl -w use strict; use warnings; use List::MoreUtils qw/ pairwise /; my @ids = (1 .. 42); my @quantities = map { 42 } @ids; my @id_stream = pairwise { (our $a) x our $b } @ids, @quantities; print join(', ', @id_stream);
It's wrong usage of Perl, not List::MoreUtils $ perl -le 'my @x = (1) x [5]; print join( ", ", @x)' perl(44710,0x7fff733e8000) malloc: *** mach_vm_map(size=1122771224645632) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Out of memory! Please file a bug against Perl5 - x operator shouldn't cause Perl dying when used wrong.