Hi, I noticed that one of my scripts is leaking memory, and after investigating it seems that the G::PB::D is the reason. Consider the following script:
#!/usr/bin/env perl
use 5.014;
use strict;
use warnings;
use Google::ProtocolBuffers::Dynamic;
my $dynamic = Google::ProtocolBuffers::Dynamic->new;
$dynamic->load_string( "person.proto", <<'EOT');
syntax = "proto2";
package humans;
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
}
EOT
$dynamic->map(
{
package => 'humans',
prefix => 'Humans'
}
);
for ( 1 .. 100000 ) {
my $bytes = Humans::Person->encode(
{
name => 'foo',
id => 42
}
);
}
when running it under valgrind I'm getting the following output (with some of it skipped):
$ valgrind --leak-check=full perl example.pl
==9258== Memcheck, a memory error detector
==9258== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==9258== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==9258== Command: perl example.pl
==9258==
==9258==
==9258== HEAP SUMMARY:
==9258== in use at exit: 10,209,010 bytes in 103,205 blocks
==9258== total heap usage: 808,722 allocs, 705,517 frees, 237,601,122 bytes allocated
==9258==
==9258== 8 bytes in 1 blocks are definitely lost in loss record 35 of 1,304
==9258== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9258== by 0x694D5FD: XS_Google__ProtocolBuffers__Dynamic_load_string(cv*) (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/lib/site_perl/5.24.0/x86_64-linux/auto/Google/ProtocolBuffers/Dynamic/Dynamic.so)
==9258== by 0x4B4CDB: Perl_pp_entersub (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/bin/perl)
==9258== by 0x4ADB52: Perl_runops_standard (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/bin/perl)
==9258== by 0x44166F: perl_run (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/bin/perl)
==9258== by 0x41FE84: main (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/bin/perl)
==9258==
... (skipped)
==9258== 9,591,072 (9,554,400 direct, 36,672 indirect) bytes in 99,525 blocks are definitely lost in loss record 1,304 of 1,304
==9258== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9258== by 0x6953502: (anonymous namespace)::make_localized_environment(upb::Status*) (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/lib/site_perl/5.24.0/x86_64-linux/auto/Google/ProtocolBuffers/Dynamic/Dynamic.so)
==9258== by 0x6958506: gpd::Mapper::encode(sv*) (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/lib/site_perl/5.24.0/x86_64-linux/auto/Google/ProtocolBuffers/Dynamic/Dynamic.so)
==9258== by 0x6950259: XS_Google__ProtocolBuffers__Dynamic__Mapper_encode(cv*) (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/lib/site_perl/5.24.0/x86_64-linux/auto/Google/ProtocolBuffers/Dynamic/Dynamic.so)
==9258== by 0x4B4CDB: Perl_pp_entersub (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/bin/perl)
==9258== by 0x4ADB52: Perl_runops_standard (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/bin/perl)
==9258== by 0x44166F: perl_run (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/bin/perl)
==9258== by 0x41FE84: main (in /home/pshaydo/perl5/perlbrew/perls/perl-5.24.0/bin/perl)
==9258==
==9258== LEAK SUMMARY:
==9258== definitely lost: 9,554,424 bytes in 99,528 blocks
==9258== indirectly lost: 36,734 bytes in 384 blocks
==9258== possibly lost: 229,538 bytes in 338 blocks
==9258== still reachable: 388,314 bytes in 2,955 blocks
==9258== suppressed: 0 bytes in 0 blocks
==9258== Reachable blocks (those to which a pointer was found) are not shown.
==9258== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==9258==
==9258== For counts of detected and suppressed errors, rerun with: -v
==9258== ERROR SUMMARY: 102 errors from 102 contexts (suppressed: 0 from 0)
The problem is present starting from module version 0.15.
Hi, I noticed that one of my scripts is leaking memory, and after investigating it seems that the G::PB::D is the reason. Consider the following script:
when running it under valgrind I'm getting the following output (with some of it skipped):
The problem is present starting from module version 0.15.