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 06:29
Subject:
Re: Trouble with PERLIO_INIT/PERLIO_TERM changes
Message ID:
456EEA53.2040506@uk.radan.com
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
perl59.dll!PerlIOBuf_close(interpreter * my_perl=0x00254224, _PerlIO
* * f=0x01823f94) Line 3994 + 0xd 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
The value of PL_perlio_fd_refcnt[fd] is already 0 at this point, hence
the croak.
(The two repetitions of the croak message (it appeared three times in
all) come from (1) further down the stack after the croak has kicked
into motion, and (2) later on inside perl_destruct(). But the above is
where it first goes wrong.)
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 (and PL_perlio_fd_refcnt[fd] is 1):
> 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
perl59.dll!PerlIOBuf_close(interpreter * my_perl=0x00254224, _PerlIO
* * f=0x01823f94) Line 3994 + 0xd 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=0x0025511c, 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 identical except that PerlIOBase_close() line 2157 calls
PerlIOUnix_close() instead of PerlIOStdio_close(). Why would this be?
Line 2157 is the (*tab->Close) call in the following:
const PerlIO_funcs * const tab = PerlIOBase(n)->tab;
if (tab && tab->Close) {
if ((*tab->Close)(aTHX_ n) != 0)
code = -1;
break;
}
Any idea what's gone wrong in the former case?
--
------------------------------------------------
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