open ${\$x} leaks #12593
Comments
From @cpansproutIf you write open $fh or open $hash{key}, the autogenerated handle is not added to the symbol table, so undef $fh or undef %hash will free it. If you wriet open ${\$fh}, it *does* get added to the symbol table, so it leaks. Is there any guarantee that a handle created like that will be accessible like this? $name = "".*$fh; Another thing: A handle created via open $hash{key} is given the name __ANONIO__. A handle added to the symbol table is given a name like _GEN_0. The latter could be useful for debugging purposes, because each handle would have a different name. Should __ANONIO__ be changed to _GEN_0? newGVgen, which creates a new handle (with a name like _GEN_0), also adds it to the symbol table. It is an API function. Should it stop adding it to the symbol table? How much of CPAN would break? I started to look, and what I have seen so far would not break, but it was only about 20 distributions. Flags: Site configuration information for perl 5.17.6: Configured by sprout at Sat Nov 17 23:09:15 PST 2012. Summary of my perl5 (revision 5 version 17 subversion 6) configuration: Locally applied patches: @INC for perl 5.17.6: Environment for perl 5.17.6: |
From zefram@fysh.orgFather Chrysostomos wrote:
Quite the contrary. perlfunc(1) describes the generated filehandle as For the glob to be sometimes interned is surprising
It's not documented, and interning isn't a crazy thing to do, so I'd But if most users of newGVgen() wouldn't be affected by it not interning, -zefram |
|
The RT System itself - Status changed from 'new' to 'open' |
|
@cpansprout - Status changed from 'open' to 'resolved' |
From @cpansproutOn Dec 9, 2017, at 5:52 PM, Zefram via RT <perlbug-followup@perl.org> wrote:
The main offender is the default typemap. Please review the attached patch. |
From @cpansproutInline Patchdiff --git a/lib/ExtUtils/typemap b/lib/ExtUtils/typemap
index 4bfba95..ca923cf 100644
--- a/lib/ExtUtils/typemap
+++ b/lib/ExtUtils/typemap
@@ -398,7 +398,8 @@ T_ARRAY
}
T_STDIO
{
- GV *gv = newGVgen("$Package");
+ GV *gv = (GV *)sv_newmortal();
+ gv_init_pvn(gv, gv_stashpvs("$Package",1),"__ANONIO__",10,0);
PerlIO *fp = PerlIO_importFILE($var,0);
if ( fp && do_open(gv, "+<&", 3, FALSE, 0, 0, fp) ) {
SV *rv = newRV_inc((SV*)gv);
@@ -411,7 +412,8 @@ T_STDIO
}
T_IN
{
- GV *gv = newGVgen("$Package");
+ GV *gv = (GV *)sv_newmortal();
+ gv_init_pvn(gv, gv_stashpvs("$Package",1),"__ANONIO__",10,0);
if ( do_open(gv, "<&", 2, FALSE, 0, 0, $var) ) {
SV *rv = newRV_inc((SV*)gv);
rv = sv_bless(rv, GvSTASH(gv));
@@ -423,7 +425,8 @@ T_IN
}
T_INOUT
{
- GV *gv = newGVgen("$Package");
+ GV *gv = (GV *)sv_newmortal();
+ gv_init_pvn(gv, gv_stashpvs("$Package",1),"__ANONIO__",10,0);
if ( do_open(gv, "+<&", 3, FALSE, 0, 0, $var) ) {
SV *rv = newRV_inc((SV*)gv);
rv = sv_bless(rv, GvSTASH(gv));
@@ -435,7 +438,8 @@ T_INOUT
}
T_OUT
{
- GV *gv = newGVgen("$Package");
+ GV *gv = (GV *)sv_newmortal();
+ gv_init_pvn(gv, gv_stashpvs("$Package",1),"__ANONIO__",10,0);
if ( do_open(gv, "+>&", 3, FALSE, 0, 0, $var) ) {
SV *rv = newRV_inc((SV*)gv);
rv = sv_bless(rv, GvSTASH(gv)); |
From zefram@fysh.orgFather Chrysostomos wrote:
Looks good to me. But there are way more of them needing the same change, -zefram |
From @cpansproutOn Dec 10, 2017, at 3:26 PM, "Zefram via RT" <perlbug-followup@perl.org> wrote:
|
From zefram@fysh.orgFather Chrysostomos wrote: You've broken something: APItest.c: In function 'XS_XS__APItest_PerlIO_exportFILE': -zefram |
From @cpansproutOn Dec 10, 2017, at 7:55 PM, "Zefram via RT" <perlbug-followup@perl.org> wrote:
I added this to APItest.xs: FILE * The code generated in APItest.c is as follows: XS_EUPXS(XS_XS__APItest_PerlIO_exportFILE) RETVAL = PerlIO_exportFILE(f, mode); Notice that RETVAL is declared as a FILE *. perlio.c declared the function thus: FILE * So how can that be an incompatible pointer type? Maybe this has something to do with it: $ ./perl -Ilib Porting/expand-macro.pl FILE But where is that coming from? ‘ack -n 'define FILE'’ includes in its output: fakesdio.h which means we have API functions (documented in perlapio) that are not callable without compiler warnings (or explicit casts).
Well this one is my fault. It’s a good thing I added a test! Fixed in d269f58. What are we supposed to do about ‘API’ functions like this? Or perhaps a more relevant question: How do we test a FILE* typemap?
|
From @iabynOn Sun, Dec 10, 2017 at 08:27:42PM -0800, Father Chrysostomos wrote:
With v5.27.6-189-gd269f58, t/op/svleak.t is SEGVing on my system. leak 2,1,sub{XS::APItest::PerlIO_exportFILE(*STDIN,"");0}, valgrind is giving me a whole bunch of: ==21957== Invalid read of size 4 I haven't looked more closely. -- |
From @cpansproutOn Dec 11, 2017, at 3:54 AM, "Dave Mitchell via RT" <perlbug-followup@perl.org> wrote:
Does the problem go away if you remove this line from APItest.xs: #include "fakesdio.h" /* Causes us to use PerlIO below */ Does the crash go away if you change FILE * in APItest.xs to FILE * and change the test in svleak.t to: leak 2,1,sub{XS::APItest::PerlIO_findFILE(*STDIN);0}, ? |
From @iabynOn Mon, Dec 11, 2017 at 08:25:57AM -0800, Father Chrysostomos wrote:
No.
No. -- |
From @jkeenanIt appears that this ticket was incorrectly marked Resolved. Re-opening, as discussion continues. |
|
@jkeenan - Status changed from 'resolved' to 'open' |
From @jkeenanOn Mon, 11 Dec 2017 03:55:42 GMT, zefram@fysh.org wrote:
Data: I'm getting warnings here when I compile blead on FreeBSD-10.3 with default compiler clang. See attached excerpt from 'make test_prep' output. 'make' completes okay, however. Thank you very much. -- |
From @jkeenan./miniperl -Ilib make_ext.pl lib/auto/XS/APItest/APItest.so MAKE="make" LIBPERL_A=libperl.a LINKTYPE=dynamic |
From zefram@fysh.orgJames E Keenan via RT wrote:
The actual subject of the ticket, open() on a general undef scalar, -zefram |
Migrated from rt.perl.org#115814 (status was 'open')
Searchable as RT115814$
The text was updated successfully, but these errors were encountered: