Memory leak with IO::Socket::INET #5867

p5pRT · 2002-08-27T09:00:16Z

Migrated from rt.perl.org#16785 (status was 'resolved')

Searchable as RT16785$

p5pRT · 2002-08-27T09:00:16Z

From swift@post7.tele.dk

Created by swift@post7.tele.dk

When I use IO::Socket::INET for socket communication i experience an memory leak!
The leak is LARGE - about 56KB of memory for every time the client program havde connected and disconnected to the server

Program flow for the client:
1. Establish a connection to the server
2. Send a short string to the server
3. Retreive a short string from the server
4. Close the connection

These 4 steps is repeated - and for each time they are executed the program EATS 56KB og memory.

Below I have attached the CLIENT and SERVER program.

CLIENT: (In this program the memory leak appears!)
-----------------------------------------------------------
#!/usr/bin/perl

use strict;
use IO::Socket::INET;
my $clientsocket;
while( true )
{
$clientsocket = IO::Socket::INET->new( PeerAddr => '127.0.0.1', PeerPort => '5000', Proto => 'tcp', Type => SOCK_STREAM );
print $clientsocket "A\n";
if( <$clientsocket> eq "B\n" )
{
print "I received B\n";
}
close( $clientsocket );
sleep 5;
}
###########################################################

SERVER: (This is OK - with no memory problems)
-----------------------------------------------------------
#!/usr/bin/perl

use strict;
use IO::Socket::INET;
my $serverSocket;
$serverSocket = IO::Socket::INET->new( LocalPort => 5000, Type => SOCK_STREAM, Reuse => 1, Listen => 'SOMAXCON' );
while( true )
{
my $clientSocket;
$clientSocket = $serverSocket -> accept();
print "Client connection accepted!\n";
if( <$clientSocket> eq "A\n" )
{
print "I'm sending B\n";
print $clientSocket "B\n";
}
sleep 2;
close( $clientSocket );
print "Client connection closed!\n";
}
close( $serverSocket );
###########################################################

Perl Info



This perlbug was built using Perl 5.00503 - Sun Mar  5 13:39:27 SAST 2000
It is being executed now by  Perl 5.008 - Thu Aug 22 10:55:24 CEST 2002.

Site configuration information for perl 5.008:

Configured by testbruger at Thu Aug 22 10:55:24 CEST 2002.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=freebsd, osvers=4.6.1-rc2, archname=i386-freebsd-thread-multi
    uname='freebsd qostest.ip.tele.dk 4.6.1-rc2 freebsd 4.6.1-rc2 #0: thu jul 18 08:24:45 gmt 2002 root@freebsd-stable.sentex.ca:usrsrcsyscompilegeneric i386 '
    config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.0/mach -Dprivlib=/usr/local/lib/perl5/5.8.0 -Dman3dir=/usr/local/lib/perl5/5.8.0/man/man3 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.0/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.0 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Duseithreads -Dusethreads -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.0/BSDPAN" -Ui_gdbm -Dusemymalloc=n'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.0/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -I/usr/local/include',
    optimize='-O -pipe ',
    cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.0/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags ='-pthread -Wl,-E  -L/usr/local/lib'
    libpth=/usr/lib /usr/local/lib
    libs=-lm -lc_r -lcrypt -lutil
    perllibs=-lm -lc_r -lcrypt -lutil
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-DPIC -fPIC', lddlflags='-shared  -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.008:
    /usr/local/lib/perl5/site_perl/5.8.0/mach
    /usr/local/lib/perl5/site_perl/5.8.0
    /usr/local/lib/perl5/site_perl/5.6.1
    /usr/local/lib/perl5/site_perl/5.005
    /usr/local/lib/perl5/site_perl
    /usr/local/lib/perl5/5.8.0/BSDPAN
    /usr/local/lib/perl5/5.8.0/mach
    /usr/local/lib/perl5/5.8.0
    .


Environment for perl 5.008:
    HOME=/home/mikri
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/mikri/bin
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/bash

p5pRT · 2002-08-27T16:23:00Z

From nick.ing-simmons@elixent.com

Swift@Post7.Tele.Dk <perl5-porters@perl.org> writes:

# New Ticket Created by swift@post7.tele.dk
# Please include the string: [perl #16785]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16785 >

This is a bug report for perl from swift@post7.tele.dk,
generated with the help of perlbug 1.26 running under perl 5.008.

I think you have re-discovered a bug in :stdio layer in perl5.8.0.
We don't have a fix for that yet but previously :perlio layer
has been shown not to have the problem.

Can you please try running the program which leaks
with PERLIO environment variable set to perlio
e.g.
PERLIO=perlio perl yourscript

Or add

use open ':perlio';

To your script.

-----------------------------------------------------------------
[Please enter your report here]
When I use IO::Socket::INET for socket communication i experience an memory leak!
The leak is LARGE - about 56KB of memory for every time the client program havde connected and disconnected to the server

Program flow for the client:
1. Establish a connection to the server
2. Send a short string to the server
3. Retreive a short string from the server
4. Close the connection

These 4 steps is repeated - and for each time they are executed the program EATS 56KB og memory.

Below I have attached the CLIENT and SERVER program.

CLIENT: (In this program the memory leak appears!)
-----------------------------------------------------------
#!/usr/bin/perl

use strict;
use IO::Socket::INET;
my $clientsocket;
while( true )
{
$clientsocket = IO::Socket::INET->new( PeerAddr => '127.0.0.1', PeerPort => '5000', Proto => 'tcp', Type => SOCK_STREAM );
print $clientsocket "A\n";
if( <$clientsocket> eq "B\n" )
{
print "I received B\n";
}
close( $clientsocket );
sleep 5;
}
###########################################################

SERVER: (This is OK - with no memory problems)
-----------------------------------------------------------
#!/usr/bin/perl

use strict;
use IO::Socket::INET;
my $serverSocket;
$serverSocket = IO::Socket::INET->new( LocalPort => 5000, Type => SOCK_STREAM, Reuse => 1, Listen => 'SOMAXCON' );
while( true )
{
my $clientSocket;
$clientSocket = $serverSocket -> accept();
print "Client connection accepted!\n";
if( <$clientSocket> eq "A\n" )
{
print "I'm sending B\n";
print $clientSocket "B\n";
}
sleep 2;
close( $clientSocket );
print "Client connection closed!\n";
}
close( $serverSocket );
###########################################################

[Please do not change anything below this line]
-----------------------------------------------------------------

---
This perlbug was built using Perl 5.00503 - Sun Mar 5 13:39:27 SAST 2000
It is being executed now by Perl 5.008 - Thu Aug 22 10:55:24 CEST 2002.

Site configuration information for perl 5.008:

Configured by testbruger at Thu Aug 22 10:55:24 CEST 2002.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=freebsd, osvers=4.6.1-rc2, archname=i386-freebsd-thread-multi
uname='freebsd qostest.ip.tele.dk 4.6.1-rc2 freebsd 4.6.1-rc2 #0: thu jul 18 08:24:45 gmt 2002 root@freebsd-stable.sentex.ca:usrsrcsyscompilegeneric i386 '
config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.0/mach -Dprivlib=/usr/local/lib/perl5/5.8.0 -Dman3dir=/usr/local/lib/perl5/5.8.0/man/man3 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.0/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.0 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Duseithreads -Dusethreads -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.0/BSDPAN" -Ui_gdbm -Dusemymalloc=n'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.0/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -I/usr/local/include',
optimize='-O -pipe ',
cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.0/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-pthread -Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lm -lc_r -lcrypt -lutil
perllibs=-lm -lc_r -lcrypt -lutil
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:

---
@INC for perl 5.008:
/usr/local/lib/perl5/site_perl/5.8.0/mach
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.005
/usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/5.8.0/BSDPAN
/usr/local/lib/perl5/5.8.0/mach
/usr/local/lib/perl5/5.8.0
.

---
Environment for perl 5.008:
HOME=/home/mikri
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/mikri/bin
PERL_BADLANG (unset)
SHELL=/usr/local/bin/bash
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/

p5pRT · 2002-08-27T16:51:41Z

From @lizmat

At 05:21 PM 8/27/02 +0100, Nick Ing-Simmons wrote:

I think you have re-discovered a bug in :stdio layer in perl5.8.0.
We don't have a fix for that yet but previously :perlio layer
has been shown not to have the problem.

Running the client part through valgrind indicates a memory leak:

==13652== 161 bytes in 17 blocks are definitely lost in loss record 6 of 16
==13652== at 0x400467C4: malloc (vg_clientfuncs.c:100)
==13652== by 0x80BC2E4: Perl_savesharedpv (util.c:948)
==13652== by 0x8066FAA: S_init_main_stash (perl.c:2755)
==13652== by 0x8062C87: S_parse_body (perl.c:1097)
==13652== by 0x8062A39: perl_parse (perl.c:1041)
==13652== by 0x805F4AD: main (perlmain.c:83)
==13652== by 0x402B4507: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==13652== by 0x805F321: strcpy@@GLIBC_2.0 (in /usr/bin/perl5.8.0-debug)
==13652==
==13652== 1155 bytes in 13 blocks are definitely lost in loss record 10 of 16
==13652== at 0x400467C4: malloc (vg_clientfuncs.c:100)
==13652== by 0x80BAC7E: Perl_safesysmalloc (util.c:78)
==13652== by 0x8067BED: Perl_init_stacks (perl.c:3396)
==13652== by 0x8060C71: perl_construct (perl.c:217)
==13652== by 0x805F466: main (perlmain.c:79)
==13652== by 0x402B4507: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==13652== by 0x805F321: strcpy@@GLIBC_2.0 (in /usr/bin/perl5.8.0-debug)
==13652==
==13652== 7232 bytes in 4 blocks are definitely lost in loss record 13 of 16
==13652== at 0x40046D9D: realloc (vg_clientfuncs.c:252)
==13652== by 0x80BAE56: Perl_safesysrealloc (util.c:122)
==13652== by 0x810B375: Perl_savestack_grow (scope.c:154)
==13652== by 0x8096AF4: Perl_block_start (op.c:2288)
==13652== by 0x808E749: Perl_yyparse (perly.y:142)
==13652== by 0x811995A: S_doeval (pp_ctl.c:2771)
==13652== by 0x811B968: Perl_pp_require (pp_ctl.c:3254)
==13652== by 0x80BA60B: Perl_runops_debug (dump.c:1398)
==13652== by 0x80652C0: S_call_body (perl.c:2045)
==13652== by 0x8064E6A: Perl_call_sv (perl.c:1963)
==13652== by 0x8069461: S_call_list_body (perl.c:4081)
==13652== by 0x8068F72: Perl_call_list (perl.c:4009)
==13652== by 0x809F72F: Perl_newATTRSUB (op.c:5131)
==13652== by 0x809A546: Perl_utilize (op.c:3437)
==13652== by 0x808F573: Perl_yyparse (perly.y:414)
==13652== by 0x811995A: S_doeval (pp_ctl.c:2771)
==13652== by 0x811B968: Perl_pp_require (pp_ctl.c:3254)
==13652== by 0x80BA60B: Perl_runops_debug (dump.c:1398)
==13652== by 0x80652C0: S_call_body (perl.c:2045)
==13652== by 0x8064E6A: Perl_call_sv (perl.c:1963)
==13652==
==13652== 143664 bytes in 13 blocks are possibly lost in loss record 15 of 16
==13652== at 0x400467C4: malloc (vg_clientfuncs.c:100)
==13652== by 0x80BAC7E: Perl_safesysmalloc (util.c:78)
==13652== by 0x80C8FEF: Perl_reentrant_init (reentr.c:143)
==13652== by 0x8060F9A: perl_construct (perl.c:275)
==13652== by 0x805F466: main (perlmain.c:79)
==13652== by 0x402B4507: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==13652== by 0x805F321: strcpy@@GLIBC_2.0 (in /usr/bin/perl5.8.0-debug)

Oddly enough, vg_clientfuncs is part of valgrind. I'm not sure how to
interpret this.

Liz

p5pRT · 2002-08-27T19:03:03Z

From swift@mail.dk

Hi Liz.

I have tried something else.
If send() and recv() are used instead of the simple print $clientsocket and
<$clientsocket> functions - the memory leak seems to disappear....

Michael

-----Oprindelig meddelelse-----
Fra: rt@x1.develooper.com [mailto:rt@x1.develooper.com]På vegne af
Elizabeth Mattijsen (via RT)
Sendt: 27. august 2002 18:52
Til: swift@post7.tele.dk
Emne: Re: [perl #16785] Memory leak with IO::Socket::INET

At 05:21 PM 8/27/02 +0100, Nick Ing-Simmons wrote:

I think you have re-discovered a bug in :stdio layer in perl5.8.0.
We don't have a fix for that yet but previously :perlio layer
has been shown not to have the problem.

Running the client part through valgrind indicates a memory leak:

==13652== 161 bytes in 17 blocks are definitely lost in loss record 6 of 16
==13652== at 0x400467C4: malloc (vg_clientfuncs.c:100)
==13652== by 0x80BC2E4: Perl_savesharedpv (util.c:948)
==13652== by 0x8066FAA: S_init_main_stash (perl.c:2755)
==13652== by 0x8062C87: S_parse_body (perl.c:1097)
==13652== by 0x8062A39: perl_parse (perl.c:1041)
==13652== by 0x805F4AD: main (perlmain.c:83)
==13652== by 0x402B4507: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==13652== by 0x805F321: strcpy@@GLIBC_2.0 (in /usr/bin/perl5.8.0-debug)
==13652==
==13652== 1155 bytes in 13 blocks are definitely lost in loss record 10 of
16
==13652== at 0x400467C4: malloc (vg_clientfuncs.c:100)
==13652== by 0x80BAC7E: Perl_safesysmalloc (util.c:78)
==13652== by 0x8067BED: Perl_init_stacks (perl.c:3396)
==13652== by 0x8060C71: perl_construct (perl.c:217)
==13652== by 0x805F466: main (perlmain.c:79)
==13652== by 0x402B4507: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==13652== by 0x805F321: strcpy@@GLIBC_2.0 (in /usr/bin/perl5.8.0-debug)
==13652==
==13652== 7232 bytes in 4 blocks are definitely lost in loss record 13 of 16
==13652== at 0x40046D9D: realloc (vg_clientfuncs.c:252)
==13652== by 0x80BAE56: Perl_safesysrealloc (util.c:122)
==13652== by 0x810B375: Perl_savestack_grow (scope.c:154)
==13652== by 0x8096AF4: Perl_block_start (op.c:2288)
==13652== by 0x808E749: Perl_yyparse (perly.y:142)
==13652== by 0x811995A: S_doeval (pp_ctl.c:2771)
==13652== by 0x811B968: Perl_pp_require (pp_ctl.c:3254)
==13652== by 0x80BA60B: Perl_runops_debug (dump.c:1398)
==13652== by 0x80652C0: S_call_body (perl.c:2045)
==13652== by 0x8064E6A: Perl_call_sv (perl.c:1963)
==13652== by 0x8069461: S_call_list_body (perl.c:4081)
==13652== by 0x8068F72: Perl_call_list (perl.c:4009)
==13652== by 0x809F72F: Perl_newATTRSUB (op.c:5131)
==13652== by 0x809A546: Perl_utilize (op.c:3437)
==13652== by 0x808F573: Perl_yyparse (perly.y:414)
==13652== by 0x811995A: S_doeval (pp_ctl.c:2771)
==13652== by 0x811B968: Perl_pp_require (pp_ctl.c:3254)
==13652== by 0x80BA60B: Perl_runops_debug (dump.c:1398)
==13652== by 0x80652C0: S_call_body (perl.c:2045)
==13652== by 0x8064E6A: Perl_call_sv (perl.c:1963)
==13652==
==13652== 143664 bytes in 13 blocks are possibly lost in loss record 15 of
16
==13652== at 0x400467C4: malloc (vg_clientfuncs.c:100)
==13652== by 0x80BAC7E: Perl_safesysmalloc (util.c:78)
==13652== by 0x80C8FEF: Perl_reentrant_init (reentr.c:143)
==13652== by 0x8060F9A: perl_construct (perl.c:275)
==13652== by 0x805F466: main (perlmain.c:79)
==13652== by 0x402B4507: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==13652== by 0x805F321: strcpy@@GLIBC_2.0 (in /usr/bin/perl5.8.0-debug)

Oddly enough, vg_clientfuncs is part of valgrind. I'm not sure how to
interpret this.

Liz

p5pRT · 2002-08-27T19:50:57Z

From nick@ing-simmons.net

Elizabeth Mattijsen <liz@dijkmat.nl> writes:

At 05:21 PM 8/27/02 +0100, Nick Ing-Simmons wrote:

I think you have re-discovered a bug in :stdio layer in perl5.8.0.
We don't have a fix for that yet but previously :perlio layer
has been shown not to have the problem.

Running the client part through valgrind indicates a memory leak:

It indicates something very odd!

==13652== 143664 bytes in 13 blocks are possibly lost in loss record 15 of 16
==13652== at 0x400467C4: malloc (vg_clientfuncs.c:100)
==13652== by 0x80BAC7E: Perl_safesysmalloc (util.c:78)
==13652== by 0x80C8FEF: Perl_reentrant_init (reentr.c:143)
==13652== by 0x8060F9A: perl_construct (perl.c:275)
==13652== by 0x805F466: main (perlmain.c:79)
==13652== by 0x402B4507: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==13652== by 0x805F321: strcpy@@GLIBC_2.0 (in /usr/bin/perl5.8.0-debug)

Since when did libc's strcpy start calling main() ?
I suspect the backtrace above main() may be suspect - though
I have not seen such a mess before.

Oddly enough, vg_clientfuncs is part of valgrind. I'm not sure how to
interpret this.

valgrind is seriously confused?

Liz
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/

p5pRT · 2002-08-27T20:13:19Z

From @lizmat

At 08:49 PM 8/27/02 +0100, Nick Ing-Simmons wrote:

Running the client part through valgrind indicates a memory leak:
It indicates something very odd!
==13652== by 0x805F466: main (perlmain.c:79)
==13652== by 0x402B4507: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==13652== by 0x805F321: strcpy@@GLIBC_2.0 (in /usr/bin/perl5.8.0-debug)
Since when did libc's strcpy start calling main() ?
I suspect the backtrace above main() may be suspect - though
I have not seen such a mess before.

It's repeatable. I though it might have had something to do with a signal
I was using to stop the client. But changing the signal to a fixed number
of times (rather than waiting until I pressed control-C) gives the same dump.

Oddly enough, vg_clientfuncs is part of valgrind. I'm not sure how to
interpret this.
valgrind is seriously confused?

Possibly. Or stuff is so messed up that valgrind gets confused? I'll
check with the author of valgrind and get back to you on this...

Liz

p5pRT · 2002-08-27T20:33:35Z

From nick@ing-simmons.net

Elizabeth Mattijsen <liz@dijkmat.nl> writes:

At 05:21 PM 8/27/02 +0100, Nick Ing-Simmons wrote:

I think you have re-discovered a bug in :stdio layer in perl5.8.0.
We don't have a fix for that yet but previously :perlio layer
has been shown not to have the problem.

Running the client part through valgrind indicates a memory leak:

Modifying client to run for 100 loops (taking sleeps out)
gives me this:

==8757== 36400 bytes in 100 blocks are still reachable in loss record 1383 of 1385
==8757== at 0x4003CE1B: malloc (vg_clientmalloc.c:618)
==8757== by 0x4039CB65: _IO_fdopen@@GLIBC_2.1 (in /lib/libc.so.6)
==8757== by 0x810FBD9: PerlIOStdio_open (perlio.c:2629)
==8757== by 0x810E512: PerlIO_openn (perlio.c:1423)
==8757== by 0x81119F3: PerlIO_fdopen (perlio.c:4406)
==8757== by 0x80EAF5D: Perl_pp_socket (pp_sys.c:2281)
==8757== by 0x80A21DC: Perl_runops_debug (dump.c:1416)
==8757== by 0x8063DCD: S_run_body (perl.c:1682)

That is _all_ the IoOFP's for the socket calls.
As predicted the equivalent leak does _NOT_ occur when using :perlio
So we now know what is leaking - FILE *s but not why. (fd refcounts??)

Unrelated but intestesingly I also see a bunch of things "like" this:

==8802== 9 bytes in 1 blocks are definitely lost in loss record 13 of 53
==8802== at 0x4003CE1B: malloc (vg_clientmalloc.c:618)
==8802== by 0x80A36DE: Perl_savesharedpv (util.c:948)
==8802== by 0x808F427: Perl_newCONSTSUB (op.c:5191)
==8802== by 0x42255466: boot_IO (IO.xs:483)
==8802== by 0x80B9ECE: Perl_pp_entersub (pp_hot.c:2746)
==8802== by 0x80A21DC: Perl_runops_debug (dump.c:1416)
==8802== by 0x80648B4: S_call_body (in /home/perl5/perlio/perl)
==8802== by 0x8064589: Perl_call_sv (perl.c:1965)

Is the "new" CONST stuff playing up or does 5.8 do that as well?

--
Nick Ing-Simmons
http://www.ni-s.u-net.com/

p5pRT · 2002-08-27T20:40:39Z

From nick@ing-simmons.net

Elizabeth Mattijsen <liz@dijkmat.nl> writes:

At 08:49 PM 8/27/02 +0100, Nick Ing-Simmons wrote:

Running the client part through valgrind indicates a memory leak:
It indicates something very odd!
==13652== by 0x805F466: main (perlmain.c:79)
==13652== by 0x402B4507: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==13652== by 0x805F321: strcpy@@GLIBC_2.0 (in /usr/bin/perl5.8.0-debug)
Since when did libc's strcpy start calling main() ?
I suspect the backtrace above main() may be suspect - though
I have not seen such a mess before.

It's repeatable.

Not by me. valgrind-20020329 on SuSE 8.0

Works fine - I have taken all the sleep() calls in scripts out though.

FWIW you get a lot less noise about leaks with

PERL_DESTRUCT_LEVEL=2 valgrind ...

as perl does more cleanup.

I though it might have had something to do with a signal
I was using to stop the client. But changing the signal to a fixed number
of times (rather than waiting until I pressed control-C) gives the same dump.

Oddly enough, vg_clientfuncs is part of valgrind. I'm not sure how to
interpret this.
valgrind is seriously confused?

Possibly. Or stuff is so messed up that valgrind gets confused? I'll
check with the author of valgrind and get back to you on this...

Liz
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/

p5pRT · 2002-08-27T21:03:53Z

From @lizmat

At 09:39 PM 8/27/02 +0100, Nick Ing-Simmons wrote:

It's repeatable.
Not by me. valgrind-20020329 on SuSE 8.0

Still the same here, with valgrind-1.0.0 and perl 5.8.0 with
debugging. Just for the record, I tried with a non-debug version of
5.8.0. The same stuff (but without the line numbers).

Works fine - I have taken all the sleep() calls in scripts out though.

Done that too.

FWIW you get a lot less noise about leaks with
PERL_DESTRUCT_LEVEL=2 valgrind ...
as perl does more cleanup.

I don't see a difference, what should I be seeing?

Liz

p5pRT · 2002-08-27T22:19:07Z

From @lizmat

At 09:32 PM 8/27/02 +0100, Nick Ing-Simmons wrote:

Modifying client to run for 100 loops (taking sleeps out)
gives me this:
==8757== 36400 bytes in 100 blocks are still reachable in loss record 1383
of 1385
==8757== at 0x4003CE1B: malloc (vg_clientmalloc.c:618)

Is this with a threaded or unthreaded Perl?

Liz

p5pRT · 2002-08-28T07:13:11Z

From nick.ing-simmons@elixent.com

Elizabeth Mattijsen <liz@dijkmat.nl> writes:

At 09:32 PM 8/27/02 +0100, Nick Ing-Simmons wrote:

Modifying client to run for 100 loops (taking sleeps out)
gives me this:
==8757== 36400 bytes in 100 blocks are still reachable in loss record 1383
of 1385
==8757== at 0x4003CE1B: malloc (vg_clientmalloc.c:618)

Is this with a threaded or unthreaded Perl?

Threaded.

Liz
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/

p5pRT · 2003-10-24T21:52:22Z

From danielt@camelot.de

Are there any news on this topic?

use open ':perlio'; doesn't work, and setting PERLIO systemwide on each
machine is a desolate job ;)

p5pRT · 2011-12-11T22:43:48Z

From @wolfsage

Is this issue still valid?

I see no leak on perl5.8.8 (non-threaded) and perl5.10.1 (threaded).

It's possible this is because of a difference in configuration, but I
suspect this may have been fixed by now in passing...

p5pRT · 2011-12-11T22:44:09Z

From @wolfsage

On Sun Dec 11 14:43:48 2011, alh wrote:

Is this issue still valid?

I see no leak on perl5.8.8 (non-threaded) and perl5.10.1 (threaded).

It's possible this is because of a difference in configuration, but I
suspect this may have been fixed by now in passing...

Whoops, cc perl5-porters.

-- Matthew Horsfall (alh)

p5pRT · 2011-12-20T03:36:15Z

From @wolfsage

On Sun Dec 11 14:43:48 2011, alh wrote:

Is this issue still valid?

I see no leak on perl5.8.8 (non-threaded) and perl5.10.1 (threaded).

It's possible this is because of a difference in configuration, but I
suspect this may have been fixed by now in passing...

I installed 5.8.0 and 5.8.3 with perlbrew; 5.8.0 reproduces the leak
with the given code while 5.8.3 does not.

I believe that this can be closed as fixed. I will wait a few weeks for
input (if any) and then do so.

Thanks,

-- Matthew Horsfall (alh)

p5pRT · 2012-01-07T20:42:29Z

From @wolfsage

This appears to have been fixed since at least Perl-5.8.3.

p5pRT · 2012-01-07T20:42:29Z

From [Unknown Contact. See original ticket]

This appears to have been fixed since at least Perl-5.8.3.

p5pRT · 2012-01-07T20:42:29Z

@wolfsage - Status changed from 'open' to 'resolved'

p5pRT closed this as completed Jan 7, 2012

p5pRT added Severity Low distro-freebsd labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Memory leak with IO::Socket::INET #5867

Memory leak with IO::Socket::INET #5867

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

p5pRT commented Aug 28, 2002

p5pRT commented Oct 24, 2003

p5pRT commented Dec 11, 2011

p5pRT commented Dec 11, 2011

p5pRT commented Dec 20, 2011

p5pRT commented Jan 7, 2012

p5pRT commented Jan 7, 2012

p5pRT commented Jan 7, 2012

Memory leak with IO::Socket::INET #5867

Memory leak with IO::Socket::INET #5867

Comments

p5pRT commented Aug 27, 2002

p5pRT commented Aug 27, 2002

From swift@post7.tele.dk

Created by swift@post7.tele.dk

p5pRT commented Aug 27, 2002

From nick.ing-simmons@elixent.com

p5pRT commented Aug 27, 2002

From @lizmat

p5pRT commented Aug 27, 2002

From swift@mail.dk

p5pRT commented Aug 27, 2002

From nick@ing-simmons.net

p5pRT commented Aug 27, 2002

From @lizmat

p5pRT commented Aug 27, 2002

From nick@ing-simmons.net

p5pRT commented Aug 27, 2002

From nick@ing-simmons.net

p5pRT commented Aug 27, 2002

From @lizmat

p5pRT commented Aug 27, 2002

From @lizmat

p5pRT commented Aug 28, 2002

From nick.ing-simmons@elixent.com

p5pRT commented Oct 24, 2003

From danielt@camelot.de

p5pRT commented Dec 11, 2011

From @wolfsage

p5pRT commented Dec 11, 2011

From @wolfsage

p5pRT commented Dec 20, 2011

From @wolfsage

p5pRT commented Jan 7, 2012

From @wolfsage

p5pRT commented Jan 7, 2012

From [Unknown Contact. See original ticket]

p5pRT commented Jan 7, 2012