Front page | perl.perl5.porters |
Postings from November 2006
Re: Trouble with PERLIO_INIT/PERLIO_TERM changes
Thread Previous
|
Thread Next
From:
Steve Hay
Date:
November 30, 2006 09:55
Subject:
Re: Trouble with PERLIO_INIT/PERLIO_TERM changes
Message ID:
456F1ACE.30604@uk.radan.com
Steve Hay wrote:
> Steve Hay wrote:
>> Jarkko Hietaniemi wrote:
>>>> refcnt_dec: fd 4: 0 <= 0
>>>>
>>>> I'm guessing that the file was opened (inc refcnt to 1), then closed
>>>> (dec refcnt to 0) and then some attempt was made within PerlIO to
>>>> close it again (triggering the croak)?
>>>
>>> That would make it, yes. Maybe fire up a debugger and set a breakpoint
>>> to the croak() in PerlIOUnix_refcnt_dec()? Compare the stack trace with
>>> the one if coming from a (Perl-level) close()?
>>
>> Here's the call stack at the point where my test.pl croaks:
>>
>> > perl59.dll!PerlIOUnix_refcnt_dec(int fd=3) Line 2355 C
>> perl59.dll!PerlIOStdio_close(interpreter * my_perl=0x00254224,
>> _PerlIO * * f=0x0025d70c) Line 3115 + 0x9 bytes C
>> perl59.dll!PerlIOBase_close(interpreter * my_perl=0x00254224,
>> _PerlIO * * f=0x01823f94) Line 2157 + 0x10 bytes C
> [...]
>>
>> If I change my test.pl to say
>>
>> open(*FH, '<', 'MANIFEST');
>>
>> instead of
>>
>> fopen(*FH, 'MANIFEST', 'r');
>>
>> then it now runs without croaking. The call stack at the equivalent
>> point is now this:
>>
>> > perl59.dll!PerlIOUnix_refcnt_dec(int fd=3) Line 2355 C
>> perl59.dll!PerlIOUnix_close(interpreter * my_perl=0x00254224,
>> _PerlIO * * f=0x01824334) Line 2717 + 0x9 bytes C
>> perl59.dll!PerlIOBase_close(interpreter * my_perl=0x00254224,
>> _PerlIO * * f=0x01823f94) Line 2157 + 0x10 bytes C
> [...]
>>
>> This is identical except that PerlIOBase_close() line 2157 calls
>> PerlIOUnix_close() instead of PerlIOStdio_close(). Why would this be?
>
> This might be because Foo::_fopen() set the filehandle into "binary
> mode" and yet the IoIFP(io) being PerlIO_close()'d contains two
> layers--crlf and stdio. That doesn't seem correct to me.
Doh! Sorry, lost the plot a bit there. The :crlf layer is present
because Foo::fopen() (back in the Foo.pm code) pushes a text mode layer
unless the caller opened the file in binary mode to start with.
So if I change my test.pl to say
fopen(*FH, 'MANIFEST', 'rb');
then the IoIFP(io) contains only one layer (stdio) and the call stack is
slightly shorter:
> perl59.dll!PerlIOUnix_refcnt_dec(int fd=3) Line 2351 C
perl59.dll!PerlIOStdio_close(interpreter * my_perl=0x00254224,
_PerlIO * * f=0x01823f94) Line 3115 + 0x9 bytes C
perl59.dll!PerlIO__close(interpreter * my_perl=0x00254224, _PerlIO *
* f=0x01823f94) Line 1399 + 0x10 bytes C
perl59.dll!Perl_PerlIO_close(interpreter * my_perl=0x00254224,
_PerlIO * * f=0x01823f94) Line 1412 + 0xd bytes C
perl59.dll!Perl_io_close(interpreter * my_perl=0x00254224, io *
io=0x002551fc, char not_implicit='') Line 977 + 0x12 bytes C
perl59.dll!Perl_do_close(interpreter * my_perl=0x00254224, gv *
gv=0x0182c17c, char not_implicit='') Line 940 + 0x11 bytes C
perl59.dll!Perl_pp_close(interpreter * my_perl=0x00254224) Line 600
+ 0xf bytes C
This is now exactly the same (w.r.t. the call stack and the layers in
the IoIFP(io)) as if test.pl had said
open(*FH, '<:stdio', 'MANIFEST');
It still croaks in the usual manner, though, whereas the open() case
doesn't :-(
Is there something wrong with my code, or something wrong with PerlIO?
--
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Thread Previous
|
Thread Next