Re: Odd (undocumented?) behavior of RAM file within a loop
- From: "A. Sinan Unur" <1usa@xxxxxxxxxxxxxxxxxxx>
- Date: Wed, 30 Jan 2008 11:05:26 GMT
Ben Morrow <ben@xxxxxxxxxxxx> wrote in
news:8v2575-srt.ln1@xxxxxxxxxxxxxxxxxxxxxxx:
Quoth "A. Sinan Unur" <1usa@xxxxxxxxxxxxxxxxxxx>:
I found it curious that the warning disappears if I commented out the
close statement (on AS Perl 5.10 on Win32).
....
Use of uninitialized value $buffer in open at C:\Temp\t.pl line 8.
SCALAR(0x182b04c)
This seems to be an bug in PerlIO::scalar.
<explanation snipped for brevity>
Thank you for your explanation.
....
I've done up a patch, which I'll send to p5p when I've tested it.
Great.
With the close statement commented out, I get:
C:\Temp> t
Pass #1
SCALAR(0x182b04c)
Pass #2
SCALAR(0x22ae14)
This makes less sense... I suspect what's happening here is that the
filehandle isn't being closed until *after* $buffer gets allocated for
the next iteration, so it is forced to allocate a new scalar since the
old one's still in use.
That is my gut feeling, too.
This is arguably wrong, since the whole point is to reuse the old
scalar if we can, for efficiency.
In fact, I would argue that it is wrong. I don't foresee myself being
able to first find where this is occurring and fix it without messing up
anything else.
On the other hand, when I used an infinite loop to see if this behavior
caused a leak, it seemed to just cycle through the same three locations
and memory usage did not increase at all.
C:\Temp> cat leak.pl
#!/usr/bin/perl
use strict;
use warnings;
while ( 1 ) {
open my $fh, '>', \(my $buffer) or die $!;
print \$buffer, "\n";
print $fh "test\n";
sleep 1;
}
C:\Temp> leak
SCALAR(0x182aeb4)
SCALAR(0x22acb4)
SCALAR(0x22ad04)
SCALAR(0x182aeb4)
SCALAR(0x22acb4)
SCALAR(0x22ad04)
SCALAR(0x182aeb4)
SCALAR(0x22acb4)
SCALAR(0x22ad04)
SCALAR(0x182aeb4)
SCALAR(0x22acb4)
SCALAR(0x22ad04)
SCALAR(0x182aeb4)
Terminating on signal SIGINT(2)
C:\Temp> perl -v
This is perl, v5.10.0 built for MSWin32-x86-multi-thread
(with 3 registered patches, see perl -V for more detail)
Copyright 1987-2007, Larry Wall
Binary build 1002 [283697] provided by ActiveState
http://www.ActiveState.com
Built Jan 10 2008 11:00:53
And:
perl leak.plSCALAR(0x1002eabc)
SCALAR(0x1002ea98)
SCALAR(0x1002eabc)
SCALAR(0x1002ea98)
SCALAR(0x1002eabc)
SCALAR(0x1002ea98)
SCALAR(0x1002eabc)
perl -v
This is perl, v5.8.8 built for cygwin-thread-multi-64int
(with 8 registered patches, see perl -V for more detail)
Copyright 1987-2006, Larry Wall
--
A. Sinan Unur <1usa@xxxxxxxxxxxxxxxxxxx>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.augustmail.com/~tadmc/clpmisc.shtml>
.
- Follow-Ups:
- Re: Odd (undocumented?) behavior of RAM file within a loop
- From: Ben Morrow
- Re: Odd (undocumented?) behavior of RAM file within a loop
- References:
- Odd (undocumented?) behavior of RAM file within a loop
- From: David Filmer
- Re: Odd (undocumented?) behavior of RAM file within a loop
- From: A. Sinan Unur
- Re: Odd (undocumented?) behavior of RAM file within a loop
- From: Ben Morrow
- Odd (undocumented?) behavior of RAM file within a loop
- Prev by Date: Re: C's gotoxy() equivalent in Perl
- Next by Date: Re: C's gotoxy() equivalent in Perl
- Previous by thread: Re: Odd (undocumented?) behavior of RAM file within a loop
- Next by thread: Re: Odd (undocumented?) behavior of RAM file within a loop
- Index(es):
Relevant Pages
|
