FAQ

Nicholas Clark writes:
This scan Coverity has 4 open bugs. Next scan may get down to just this one:
Comments inline below... I think it is all right, but
Coverity dislikes the call to PerlIO_findFile in ext/XS/Typemap/Typemap.xs:

Specifically, it says:

1106 XS(XS_XS__Typemap_T_STDIO_print); /* prototype to pass -Wmissing-prototypes */
1107 XS(XS_XS__Typemap_T_STDIO_print)
1108 {
1109 #ifdef dVAR
1110 dVAR; dXSARGS;
1111 #else
1112 dXSARGS;
1113 #endif
1114 if (items != 2)
1115 Perl_croak(aTHX_ "Usage: XS::Typemap::T_STDIO_print(stream, string)");
1116 PERL_UNUSED_VAR(cv); /* -W */
1117 {

Event alloc_fn: Called allocation function "PerlIO_findFILE" [model]
Event var_assign: Assigned variable "stream" to storage returned from "PerlIO_findFILE"
Why does it think PerlIO_findFILE returns storage?
It returns a pointer to a structure accounted for elsewhere.
Also see events: [var_assign][pass_arg][leaked_storage]

1118 FILE * stream = PerlIO_findFILE(IoIFP(sv_2io(ST(0))));

At conditional (1): "(*(PL_stack_base + ((ax + 1) * 4)))->sv_flags & 1024 == 1024" taking true path

1119 const char * string = (const char *)SvPV_nolen(ST(1));
1120 int RETVAL;

At conditional (2): "(PL_op)->op_private & 32 != 0" taking true path

1121 dXSTARG;
1122 #line 817 "Typemap.xs"
1123 RETVAL = xsfprintf( stream, string );
1124 #line 1125 "Typemap.c"

At conditional (3): "(targ)->sv_flags & 4194304 != 0" taking true path

1125 XSprePUSH; PUSHi((IV)RETVAL);

Event leaked_storage: Variable "stream" goes out of scope
Yes, but the IO * is still about.
Also see events: [alloc_fn][var_assign][pass_arg]

1126 }
1127 XSRETURN(1);
1128 }


I'm having trouble following the logic of PerlIO_findFILE(), and clearly it is
too. Specifically, I think the relevant execution path here is call to
PerlIO_findFILE():


FILE *
PerlIO_findFILE(PerlIO *f)
{
PerlIOl *l = *f;
while (l) {
if (l->tab == &PerlIO_stdio) {
PerlIOStdio *s = PerlIOSelf(&l, PerlIOStdio);
return s->stdio;
}
l = *PerlIONext(&l);
}
/* Uses fallback "mode" via PerlIO_modestr() in PerlIO_exportFILE */
return PerlIO_exportFILE(f, NULL);
}


which in turn calls PerlIO_exportFILE():
_May_ call exportFILE() - if we are using :stdio already
it just returns a pointer to the existing FILE struct.

/* Note that calls to PerlIO_exportFILE() are reversed using
* PerlIO_releaseFILE(), not importFILE. */
FILE *
PerlIO_exportFILE(PerlIO * f, const char *mode)
{
dTHX;
FILE *stdio = NULL;
if (PerlIOValid(f)) {
char buf[8];
PerlIO_flush(f);
if (!mode || !*mode) {
mode = PerlIO_modestr(f, buf);
}
stdio = PerlSIO_fdopen(PerlIO_fileno(f), mode);
if (stdio) {
PerlIOl *l = *f;
PerlIO *f2;
/* De-link any lower layers so new :stdio sticks */
*f = NULL;
if ((f2 = PerlIO_push(aTHX_ f, PERLIO_FUNCS_CAST(&PerlIO_stdio), buf, NULL))) {
PerlIOStdio *s = PerlIOSelf((f = f2), PerlIOStdio);
s->stdio = stdio;
/* Link previous lower layers under new one */
*PerlIONext(f) = l;
}
else {
/* restore layers list */
*f = l;
}
}
}
return stdio;
}

and as far as I can tell, if that succeeds in allocating a FILE * (which seems
to be the alleged leak) then that FILE * is assigned to s->stdio, which in
turn is still reachable via the original variable f.
Which in turn is reachable via the original IO *

As so often happens this exactly the code that is
involved in the xsclose() thing in another thread.


(It helps to know
typedef PerlIOl *PerlIO;
ie the parameter f is actually PerlIOl **f
)

So I think that this leak is false. But it would be nice to have a second
opinion.
What has caused it to believe "PerlIO_findFILE" is an "allocation function"
i.e. what does "[model]" mean?
Nicholas Clark

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 2 | next ›
Discussion Overview
groupperl5-porters @
categoriesperl
postedApr 18, '06 at 1:38p
activeApr 20, '06 at 8:20p
posts2
users2
websiteperl.org

People

Translate

site design / logo © 2019 Grokbase