5.6, source filters, modules, and __END__ go boom

[p5pRT]

Migrated from rt.perl.org#2717 (status was 'resolved')

Searchable as RT2717$

[p5pRT]

From gnat@frii.com

When you have a source filter in a module that has an __END__ or
__DATA__ block, Perl cores after executing the code in the module.
Yes, I know modules aren't supposed to have __END__, but it does
the same thing with __DATA__.

Main program​:

  #!/data/perl/bin/perl -w

  use Module;

Module.pm​:

  package Module;
  use MyFilter;
  warn "executing\n";
  1;

  __END__

MyFilter.pm​:

  package MyFilter;
  use Filter​::Util​::Call;
  sub import {
  my ($type) = @​_;
  filter_add(bless []);
  }
  sub filter {
  filter_read();
  }
  1;

This was originally from Rocco Caputo, the POE author. The core is
coming when an SV is cleared​:

#0 0x28163a6c in closedir () from /usr/lib/libc.so.3
#1 0x809cf74 in Perl_sv_clear (sv=0x80f4508) at sv.c​:3624
#2 0x809d236 in Perl_sv_free (sv=0x80f4508) at sv.c​:3785
#3 0x8091871 in Perl_av_undef (av=0x80f4628) at av.c​:452
#4 0x809cfc2 in Perl_sv_clear (sv=0x80f4628) at sv.c​:3640
#5 0x809d236 in Perl_sv_free (sv=0x80f4628) at sv.c​:3785
#6 0x80ae156 in Perl_leave_scope (base=137) at scope.c​:675
#7 0x80acfb1 in Perl_pop_scope () at scope.c​:144
#8 0x80b5f91 in Perl_pp_leaveeval () at pp_ctl.c​:3357
#9 0x8092a52 in Perl_runops_standard () at run.c​:25
#10 0x805b716 in S_call_body (myop=0xbfbfd9a8, is_eval=0) at perl.c​:1761
#11 0x805b4ef in perl_call_sv (sv=0x80f270c, flags=6) at perl.c​:1677
#12 0x805dbe4 in S_call_list_body (cv=0x80f270c) at perl.c​:3600
#13 0x805d950 in Perl_call_list (oldscope=1, paramList=0x80f279c)
  at perl.c​:3528
#14 0x807c06f in Perl_newATTRSUB (floor=78, o=0x80e7da0, proto=0x0, attrs=0x0,
  block=0x80f34c0) at op.c​:4641
#15 0x807963b in Perl_utilize (aver=1, floor=78, version=0x0, id=0x80e7d00,
  arg=0x0) at op.c​:3162
#16 0x8073764 in Perl_yyparse () at perly.y​:377
#17 0x805aae4 in S_parse_body (env=0x0, xsinit=0x8058924 <xs_init>)
  at perl.c​:1249
#18 0x805a0cf in perl_parse (my_perl=0x80e8030, xsinit=0x8058924 <xs_init>,
  argc=3, argv=0xbfbfdbf0, env=0x0) at perl.c​:857
#19 0x80588ec in main (argc=3, argv=0xbfbfdbf0, env=0xbfbfdc00)
  at perlmain.c​:50
#20 0x8058829 in _start ()

Source filters use the directory portion of the IO SV. They have a
flag to mark the directory handle as fake. Somehow there's an SV
with the compiled code that has the directory handle flag set, but
which isn't a directory handle. I assumed it was the copy of rsfp
that's made in toke.c's handling of __END__, but even when I made
sure the fake flag was set on the new IO structure, it was still
coredumping in the same way.

Here's the offending IO sv​:

(gdb) print *(struct xpvio *)sv
$2 = {xpv_pv = 0x80ea700 "`W\021\b", xpv_cur = 0, xpv_len = 67371023,
  xiv_iv = 135173528, xnv_nv = 2.5653433295941419e-289, xmg_magic = 0x80f38c0,
  xmg_stash = 0x9, xio_ifp = 0x600d, xio_ofp = 0x80e95a4, xio_dirp = 0x1,
  xio_lines = 67371012, xio_page = 135494240, xio_page_len = 1,
  xio_lines_left = 12, xio_top_name = 0x8104b90 "", xio_top_gv = 0x1,
  xio_fmt_name = 0x2000100b <Address 0x2000100b out of bounds>,
  xio_fmt_gv = 0x80f22ac, xio_bottom_name = 0x3 "", xio_bottom_gv = 0xc,
  xio_subprocess = -18532, xio_type = 14 '\016', xio_flags = 8 '\b'}

Perhaps it's something that isn't an IO SV but which is marked as
such? I lack the patience to step through and see where this is going
wrong, so I'm hoping someone (Sarathy? Paul?) can spot the cause
immediately.

Nat

[p5pRT]

From @gsar

On Sat, 25 Mar 2000 23​:15​:33 MST, Nathan Torkington wrote​:

This was originally from Rocco Caputo, the POE author. The core is
coming when an SV is cleared​:

#0 0x28163a6c in closedir () from /usr/lib/libc.so.3
#1 0x809cf74 in Perl_sv_clear (sv=0x80f4508) at sv.c​:3624
[...]
Source filters use the directory portion of the IO SV. They have a
flag to mark the directory handle as fake. Somehow there's an SV
with the compiled code that has the directory handle flag set, but
which isn't a directory handle. I assumed it was the copy of rsfp
that's made in toke.c's handling of __END__, but even when I made
sure the fake flag was set on the new IO structure, it was still
coredumping in the same way.

PL_rsfp doesn't have IoDIRP set, so the IOf_FAKE_DIRP flag is not
applicable there.

Here's the offending IO sv​:

(gdb) print *(struct xpvio *)sv
$2 = {xpv_pv = 0x80ea700 "`W\021\b", xpv_cur = 0, xpv_len = 67371023,
xiv_iv = 135173528, xnv_nv = 2.5653433295941419e-289, xmg_magic = 0x80f38c0,
xmg_stash = 0x9, xio_ifp = 0x600d, xio_ofp = 0x80e95a4, xio_dirp = 0x1,
xio_lines = 67371012, xio_page = 135494240, xio_page_len = 1,
xio_lines_left = 12, xio_top_name = 0x8104b90 "", xio_top_gv = 0x1,
xio_fmt_name = 0x2000100b <Address 0x2000100b out of bounds>,
xio_fmt_gv = 0x80f22ac, xio_bottom_name = 0x3 "", xio_bottom_gv = 0xc,
xio_subprocess = -18532, xio_type = 14 '\016', xio_flags = 8 '\b'}

Perhaps it's something that isn't an IO SV but which is marked as
such? I lack the patience to step through and see where this is going
wrong, so I'm hoping someone (Sarathy? Paul?) can spot the cause
immediately.

If I were you, I'd check Filter to see if it creates any io structure,
and if it does, fix it to set IOf_FAKE_DIRP on such io.

Sarathy
gsar@​ActiveState.com

[p5pRT]

From @gsar

On Sat, 25 Mar 2000 22​:41​:55 PST, I wrote​:

Perhaps it's something that isn't an IO SV but which is marked as
such? I lack the patience to step through and see where this is going
wrong, so I'm hoping someone (Sarathy? Paul?) can spot the cause
immediately.

If I were you, I'd check Filter to see if it creates any io structure,
and if it does, fix it to set IOf_FAKE_DIRP on such io.

A quick look shows Filter/Call/Call.xs annihilates IoFLAGS​:

  #define CODE_REF(sv) IoFLAGS(sv)
  [...]
  void
  real_import(object, perlmodule, coderef)
  [...]
  CODE_REF(sv) = coderef ;

Oops.

Sarathy
gsar@​ActiveState.com

[p5pRT]

From [Unknown Contact. See original ticket]

Gurusamy Sarathy writes​:

A quick look shows Filter/Call/Call.xs annihilates IoFLAGS​:

\#define CODE\_REF\(sv\)            IoFLAGS\(sv\)
\[\.\.\.\]
void
real\_import\(object\, perlmodule\, coderef\)
\[\.\.\.\]
        CODE\_REF\(sv\)   = coderef ;

Oops.

I think the idea is that this is a special kind of SV, which ought
never to be released into the wild. I've spent >1 hour in gdb and
the source code wondering just where that SV is and why it's being
freed, and I've decided it's beyond me :-)

If someone would like to go through that stack trace showing me
which functions correspond to what compiletime/runtime action, I'd
be forever grateful.

I've worked out​:

main Perl parse
  #16 0x8073778 in Perl_yyparse () at perly.y​:377

use Module
  #15 0x807964f in Perl_utilize (aver=1, floor=78, version=0x0, id=0x80e7d00,
  arg=0x0) at op.c​:3162

execution of the Module's code in a BEGIN block or is it that 'use'
corresponds to BEGIN { require ... ; import ... }?
#14 0x807c083 in Perl_newATTRSUB (floor=78, o=0x80e7da0, proto=0x0, attrs=0x0,
  block=0x80f34c0) at op.c​:4641

These are from the execution of the module's code​:
  #9 0x8092a66 in Perl_runops_standard () at run.c​:25
  #10 0x805b716 in S_call_body (myop=0xbfbfd9a8, is_eval=0) at perl.c​:1761
  #11 0x805b4ef in perl_call_sv (sv=0x80f270c, flags=6) at perl.c​:1677
  #12 0x805dbe4 in S_call_list_body (cv=0x80f270c) at perl.c​:3600
  #13 0x805d950 in Perl_call_list (oldscope=1, paramList=0x80f279c)
  at perl.c​:3528

When the file scope of the module's code ends, there's scope cleanup​:
  #6 0x80ae16a in Perl_leave_scope (base=137) at scope.c​:675
  #7 0x80acfc5 in Perl_pop_scope () at scope.c​:144
  #8 0x80b5fa5 in Perl_pp_leaveeval () at pp_ctl.c​:3357

And now there's the weird mess of things being freed, which I can't
track down​:
  #0 0x28163a6c in closedir () from /usr/lib/libc.so.3
  #1 0x809cf88 in Perl_sv_clear (sv=0x80f4508) at sv.c​:3624
  #2 0x809d24a in Perl_sv_free (sv=0x80f4508) at sv.c​:3785
  #3 0x8091885 in Perl_av_undef (av=0x80f4628) at av.c​:452
  #4 0x809cfd6 in Perl_sv_clear (sv=0x80f4628) at sv.c​:3640
  #5 0x809d24a in Perl_sv_free (sv=0x80f4628) at sv.c​:3785

Nat

[p5pRT]

From @pmqs

From​: Gurusamy Sarathy [gsar@​ActiveState.com]

On Sat, 25 Mar 2000 22​:41​:55 PST, I wrote​:

Perhaps it's something that isn't an IO SV but which is marked as
such? I lack the patience to step through and see where this is going
wrong, so I'm hoping someone (Sarathy? Paul?) can spot the cause
immediately.

If I were you, I'd check Filter to see if it creates any io structure,
and if it does, fix it to set IOf_FAKE_DIRP on such io.

A quick look shows Filter/Call/Call.xs annihilates IoFLAGS​:

\#define CODE\_REF\(sv\)            IoFLAGS\(sv\)
\[\.\.\.\]
void
real\_import\(object\, perlmodule\, coderef\)
\[\.\.\.\]
        CODE\_REF\(sv\)   = coderef ;

Oops.

I can't reproduce the __END__/__DATA__ problem on my Linux box at all
(Mandrake 6.1), but I've removed the use of IoFLAGS anyway. I don't think I
need to set the IOf_FAKE_DIRP flag in the filters myself because toke.c
takes care of it. I've also added a couple of tests to check that __END__ &
__DATA__ will work with Call.pm

This patch applies over a fresh copy of Filter-1.17. As well as the
__(END|DATA)__ problem, it includes Sarathy's threading patch. If it works
for those folk who were having the __(END|DATA)__ problems, I'll upload it
to CPAN.

Paul

begin 664 Filter-1.18.patch.gz
M'XL(".V*WC@​``T9I;'1E<BTQ+C$X+G!A=&-H`-T<​:U/;2/*S\RL&0BV2+<"2
M7]@​$;@​D8XEU>91LV5TE.*ZPQ5L66O)(,X;C\]^ON&;V,3"`AR=ZYP%@​S/3/=
M/=T]_1AC.\,A6QOX[,`9A]Q?T]?UQL​:>-1[3V_JG(-6QF>EX42P6%XXJ]&><
M'5NWS*@​QH]PJ-UO&)M.;S>​:+M;6UA5,6>C,71OG,J#.CTBK76WH5AI?+N%;Z
M16L;6I/1`V.,,.&N->&LQ2($J5V\[\["D>?#QQ8[LV9C7.2O&0\"]F()N_>M
MD#-&W7HM'+%]/N"32^XCRC4!<L']P/%<`EDO5VE​:>MN`=Z(*\8&_​:\^+CU$'
M?*![,!*<R$&F-H=,'K-T78,=D.QZZ;B#\<SF;'G*_?'Z​:#G3]K9W_EJTP<]&
MD=E\>'7-)K,@​9)><68,!X,EM9H/D<)^[X?B6S5P;F!6.?&[9T(6S"EQ@​^'[[
MH'?!>,BL,;-\SAR7U=;+Y​:I9JPN8E\X0A@​\%(-#W$AX<EXOG0N'PNG>A$`XJ
M`G,7%HYQZ[@​@​2"[,+,8$<D8YPUF[>V0>G^Z?'[650"T4.M[KTW[_]-@​\V3W&
MEGG0T]>_M??Z$K1_>F8>7F2A#CI'_7;7W-WK=RYHRHYWU#EI][)0K\\/S-.#
M@​UX;IKI6&0.HL]W#MGG4/L&&%(E[I_MML]L^D'``>'"T>]@​C*"(Q`H2YY'`-
MQ$IE[U^P^&5[[([UKL\NWN*X=]#_@​6VSU??EU2UHWCOOF@​$/<23#H5OL,[L9
M@​7`RI​:R2W()H5"N1Y#Y​:-$KQOA'K+MK=7N?T!)L1IV06*QR,QOR​:TURR-\WS
M;ONB@​R,+M;Q>.6WA;+>_]^​:H?=$^RH,"K"+`Y",""F$I_2Q!3N'Y!6%.N#GM
MOWD[1^.")G.NS;H/9D5@​,2-*_Z^*@​X`_3F_R3&REHE6-R,0&H14Z`Y"1D`UF
M/DJ7Z=B?V)9`3_9V*@​;0-*33T!S`*​:$`C,8N9T,3EYU8GW!E-/FD4B&#[BWY
M"*)8%(!;*0`Q!%>YDY0"')P+DUL`!.KD/NSO]G=Q+75+0@​U&<.H6W3&`++]W
ME[?(,%0WM5HU,@​Q?21`)​:H2[EL)​:2^&K?CN^^6?>IJ8;%;$E9.DJ94VOU.-3
M&EX%?#L[[[TYWNW^K@​13-​:*(.IPA4V)1(YQ4%3`MB5Y0(P3H77=/?U?2>A!!
M_O(+"%+_GV=MA+G(`U'9]C​:0')IG%WL7,+50PQ@​Q(M6;`​:.VR1813V&@​HO0N
MBNK]^31V​:/;V=H]VN\0IFN-S](&/`P[(V[D>W\ARK_B<LR?​:[OMYHKUPX#OH
M*#&]##^M2KU56>3BR0$I[TX'UZ[6JAB+O3N]IFMZ+;UYU+"9;!YX4;;MA.@​'
M>4-BCQ"\]​:EGK[/^R`D8_(0CL`+>S!]PB5,`QAMD%11YZ'L3R>T^0)VAL?\-
M0,$L@​G0&`;BPNLXLU\9Y'!M$W@​'^L]"C28=H"\*1!9(=R%EL)PA]YW(6PM%Q
MXX#?1E.";L""[A4U74O/#4^.FEFOK`NCC'QBP!\;7>8YCZ\D2"8X\B!S=[#]
MB0_H;=YG3W?<V\MTY^-]]LRHY_'9N43PZWSV1LPQPC?'1ZX\Q6'_)F0>X;#/
M1P^Y\E_78!_NGR9#FU_.KL`>E"-+E>N'+​:4]N8P/MI0]NE/^UUQ/CN\U!Y'O
M=V6==,`NNQ!​:O!J​:1B6]"GO%JNP__YEK!-`J@​LZMQEYMLT​:-J=)_)4[=/Z8>
MSZD'/-​:E!SW6G-Y\KCW.8_V1G,OU8`RMTD@​L+CPF@​4&,'/MQ_FK&E3OKG+7-
M#CF"B?=XK<Y#G)[W)4CL$>​:16FMJ]682#P^1E/->V^R_Z;9W]WO2H(,YGPU"
M<?2*H(`5"U,+O9^M]&Y]QI#!\J^RWM"UY]BP^5-GRLT;WPFY`B`!^G/8PXKX
MQ-*^FIB$%4-\WV9*]*PB9.3ZH`M%OA%"K>V@​_X>;5​:]IC482Q7T30​:7T!)UH
MAA+-@​$<​:!0]3G\,[#(_'EY[.D(01ZC/P(6^C&X​:V&7OED9L,+T+"FZ%GE98;
MMI4"\ZT;9)')P;\`,Y+ITFXT\K37J&GH<[F[6P^Q'SS&6<#)?1!,6PU$C"GW
M8N`!9S^%B1>(\0M,H0@​​:Q1@​U(WJTNN<K6UNJ?+J3CF-TS&V6M68E[?,^,P=^
M)+T/2B​:9.IK@​[?P$J1#X_G8]S,+<P]FH02!1C<3J<T;*@​3F1D".1%$%2\)/$
M<QCD%!E(+\9N,CB*/PNPC&%([Y@​#7L1VVAIF-NS!?14Q4%W3(4Z5\O`PZD+'
MM"1^RX_9G@​F]A6%`74\K,+XP4W#2?BM&;M-CK[_;I6=I<VA)",^6R-*8Y(5S
M&\.W)5​:8LS`3"*N\@​1(X_P9!E^9&%2%49%T`"DR,-#​:X7=LB&E\@​_86T``(L
M]&34M@​"J(94`HB,;0@​F(,09C#Q-2-R/8_I215!F86@​A+9)*F8%[R*V`FC582
M.*VL27NJXN("_0SQ@​(<NI0#./[UAI*W"=V"KY&11_='\760FYD>AOY$YMW[B
MMN1*_^​:FIC<;D?3_+YF99E,SRK64]_AWMC)&T]",9C.7S])IF5@​?N>EZ[B4(
M\D=EJ$HNLF&*@​=C0;?<O=H\B=(@​2#\**;38<N.%8&6KLP#QL]P^.5,&H2KFL
M5<KU7$;E+DVAC?KUB^8Z_GI#JU1B*RL=ZL(?W4Z_W2WH>4@​%4^O&W?,F$U`3
M9>B,-3C,Z4'#HQ[B​:$RUP.<R_.IJ`48<=([​:((X`BR(H,GC1()9J2H​:_^Q!+
M*[​:7,T]Z++I2U__HG%2,E)$"N.D[XP,@​!N]IKU%H1`+EC>T@​M$%8-/G1<>7>
M&%5@​2^)5/Y4MY"N?LJ)@​#U$7,TD\IFD5<E]$CHD/R+9\"LF^R​:#)3N<551%0
MR8#HQG$KAHFJH$PU5QNJ+/TP5R!Y!I[EB5​:UUM"J]7JN​:F72Q9AT^0[Y;UB#
MR28YC-'`(<0N>?EE2GS7*X!S,U<G[^/\Y!3W4U'*S?<=@​U'`%.3ZV5$F-Y=J
M)_XO&$/)OAZ?,F,3DWUZHU6KY"?[TH/2N3Z]5​:VUC/(#&5Q-+T?;CE%`^U-X
M'CKCH-7"*?'7)Y]B"<[1OV​:.SRDI​:D3)FC_PB(P65_#0Q.*38-GV#EL5.*YJ
MZ'=$V0W1@​[1".XQ8'3ON1P@​P5D7/W5'GY'?,QQ/8ZF<!@​UG;U0("%.[V3H_/
MNNU>;WMG]>K?SG05MO/\X*#SEI[E`&7E`]O9%AE<<=​:!*Q7)RL.$OFX?=C#C
M="=%UG8X6X[2TB[G=B!2QNDL<95Y/KOD(<!H[-​:;@​6-RS=G*A_<N9J<*8`<`
MGU<2%'5!SGUC^2Y;INEJZ_7U<C(-^C1!Z'ONU?@​6>(\F">P`^"$0!+$_T&​:D
MYO[7*>-_L=7C'G6L8DXI7J].ZWU^AOW​:_%'[E​:M+Z!X"JFFI%TWW-$@​TSY<^
M&@​M+'Q)^3F_J+7WS<7KSQ5>VM($CY/8__(KRT4C4HP?I97$U1I"​:'K7G36]]
MYVH4,F6@​TJ69-83)ILK7V>YXS`@​L`+$+N'_-[?4TD52SF?K>%1R***08IK/`
M&X8@​RWR+A']@​N3`V*;0P)\0*S8;GYW`+G"!G>(L@​45T?IL,4/_!J$C!+​:IL3
M!GP\)$PB?2[/1T8+7]^^`9N/'A25%H3LL(<W`&'^!S<@​USVO@​'<>J<1K#F​:*
MQ[A<SIRQG5?E0P`TJ5BO(Y-)13L/`E%PBZY>H+\`1_IX#!"P#P#ML^`V"/FD
M]2)F;)%)^XGG4FP_A;WK#,4@​04$`)WJ`U49`*6.]S5I-HZ67/1]8L`RD!R$@​
MY+L`#]/<.+`GE\"6C\YTBMM!E2DB6(K@​3R*X^J,(SC7)-A_XM],P^CM?U+S?
M?<]4WP=Y?($S9^SSE#E3^+*_0Z7S6_'Y'L7.N1K8,]0V8&gt;U%U4TDXS$%3O9W
M*7`^ACM(U-/KF1&7YOL7<FH>\.=S*T^V*F6M4DL5-<M​:DOW.(/?#[N!1763@​
MH35VX20.IGS@​#"&TE!=+N$LZB1H$AG]BA=F[>7O=?Y[US>/=P\Z>J1?*GX;#
M!9T&="ZP3^)FE]2W+]X&E!'IWNGY273'3]16<V[X85W6/#F=N^*WE`+K]OIF
MOW,<72R4%U[G[NVU3P0E=(]PT​:7""*@​G@​,2EJ.Q0H4!P(M7U​:,]_+KD$8QZU
M#_K?D>​:\+​:]7M,9\@​H_*;?MM,?8U!$Y($=Z6U%RUD%R!C"!H38VY​:B8A,G,#
MY\KEF/S​:%Z>)XKB4_?!FH2FN;5(&B5HI8J1'T1LG\3#S_H;[E'"_&>$'U`5K
M$,YHGV*5""'"!!]U;('GDQQPC;+6J,_EZ;X7=8B]I!`_1E1^*QEYF]​:L0RA2
M>ZC,V.66_5KDA3'YA$AAE25*3T<)_R2%MQ231(""_XS40EP'X)\`V_%M471?
MWH+[1C?EB!`7J[4B^944;6DAK-_`@​"BI)​:_*ZE@​8HC.LC%%5XZ&R8XJ4="X-
M2<J@​K'Y_C'-]%+VFZ8​:1OQG1S0​:?QSI@​?[J7N4Q2@​!O%`KC3*6N/]]"MT!*7
M!0-Q>]!B([R&[J,C+I)#<$+8'@​1D$XZBYKA.Z%AC)[!(I"#*HOB``PQ(/PF?
MO.#?H'NPN;S/P5R@​J_X,=',97P4MJ"W0@​DPZUDYX__>Y1​:U7&W21-9?[N>C_
MJ#O3#P9><J-SPR+91[OSP-C",6PSYHL@​EH5XRVA`V(1A2V-AO!4-3-\4KK5J
MQL/!5E.+KF)0K--$?R]Q\/#E3;G+E`.-+;]​:P?3DLHI"2MG7/<MUO5!`4%^+
MK2P!>^)JAQA["F-W5NX0X//Z=.$$,4`RB[AQ<NFX5)([39717[)#'I)689=L
M7)&5.P4EA!VH[PPL@​N5N5;B!U\'7LWL4-=[;G*CC\;L2CTC'OD​:K8F"Z\X&+
MVYH1.QHKX%VAL<!J[;+X+#B[0L5,T4X?13-9(A3R97U]W​:A&^X"'.NMC'H'[
M/C!^8`4<(]​:7]U[R=@​.B($7@​VU#8_`H4\KA2-3#N2,4AHB'S7827XCP;.CZL
M,@​8/)CJMADQ15E`>9@​'6=(6UH-*YJK(=5E​:%ZS$8>5,2N$*P\=Y?V=B@​JP8O
MZ0​:[Z]V([!N'P,.FV9D")IBR,=84A->.+C^1%.​:O%BO%YUPBZT9%JR>9.GQ-
M;AF@​SL=#O$_RJQE/(-II$3EK9'\7$FO2.​:_4TS1'KV#C3;O;WNC3^U6,))/N
M8=VH​:O5*)JG[_(@​UGXA8+@​<KFUJ]&H=F[=-C>)?B")]P%M9AU@​1PPC_4$+6'
M'GY[X`H/T]";>""E-Y'PBGDD+RI-6"*VD`\NL?KD%7*)@​@​.\GAS@​WD<%Y`2X
M_`^VL[-)WX`I"U9C3U5C*Q​:6G%Z]@​CG52"7[3R4]Q@​E^9B[6E81YI\375M*X
MO'('%G=&5GNR+&^OU.',;M3C[YI\%<;SC"0*8DKR,%XBC*F`=R?^O&1[(PXV
MRJ33W#2Q*>>%$@​J_=*D(DWL*$$46C6C2!&+X9Q7^KJH4!4RMP4?KBK,(4H0&
M091.;K6PA-EJX7>7J8O%Z.&G8';)G,G4\\-4-9-4)[R=<E2I8.0,PW@​DOJ3&
M6+​:M7%+N^-T'IE+],)E3P,S/F5'3I3PU77J$FJ​:,Y=(B_5R2^IG,%TVUE<)4
MIZ>$&PGC8Q'+9SKR5QX[R0Q2]T@​L\(U\LR7VJP7HO\)]W]F*H7ZU\'-*')ZH
MKE(K2I3N6L$5_ERA?/Y​:9YVM=-Q!2DF8L?.+_B<=*"CFM1P%$#WU>PI0DE(N
M9+Z4PK*48%E​:C&5)8@​D_G\6?._$G48CVR;Y)​:;4\?1#T/4$?2GGZ4%JL#V*!
MA)4I?1"X+M0'`;]8'P3%T9Q2'^;FS.A#*4\?DE4>I0^E1?I0DOJ0S)?H0X*I
M3D\)-QZI#Z6L/D0SY.I#*​:L/I90^E%+2\+6"]G1U​:"Q4A\WOJPY//]'R@​P?.
M\7>^L)8TWP\@​XJ['%])28YZG@​"9Q8U]5K,+["[_-@​+.+_JT'S4AO7RZ=?1,F
M7RZ;Z7.XY(9​:NF94DR\Q/?J?>N0E'X"<)^9-)"1[Y/T[`91<`L48%Y^**NM=
M=RZ4^;1%]DJO-[9-O*Z\+;Z​:KXBU(P^=Q​::.*0)*SH;W;W"VDGZ/,)6]VBZS
M.#])_Q_EZ_\)QG<O&2W​:LZ^_?2@​V)+JC&FV)>/[YFY(;1%>U6N​:K("*E58BL
MH&S%;^SCG8​:"R(OA73<.`<,V<_E-[\*Y5LK"&RNDA)&>Y05DF8%9OHDC_T+J
MK$YXK\F9Q95^K.F1;X*WZ$1$C​:H;_2.%6CKX_$​:\,WN6B_GE<Z">MP6UBE​:+
M33/]6X%2B65.H?@​?)Q3C9C@​?5W=6998B\C2RXX"&0H2]M9Q,1/^]@​-[(D1%"
K*N@​W,>6F)`X&#A?_4.'D_.A(%>​:[UH#`/V+]]\+W\ID0_B\[)E@​SC4L`````
`
end

[p5pRT]

From [Unknown Contact. See original ticket]

On Sun, 26 Mar 2000 22​:26​:58 +0100, Marquess,P,Paul,NEL38 R wrote​:

I can't reproduce the __END__/__DATA__ problem on my Linux box at all
(Mandrake 6.1), but I've removed the use of IoFLAGS anyway. I don't think I
need to set the IOf_FAKE_DIRP flag in the filters myself because toke.c
takes care of it. I've also added a couple of tests to check that __END__ &
__DATA__ will work with Call.pm

This patch applies over a fresh copy of Filter-1.17. As well as the
__(END|DATA)__ problem, it includes Sarathy's threading patch. If it works
for those folk who were having the __(END|DATA)__ problems, I'll upload it
to CPAN.

Paul

The problem happens on my FreeBSD machine, even with your attached patches.
Oddly, I've found a work-around​: simply don't allow the __(END|DATA)__
line to be parsed​:

  # Treat it as EOF.
  if (/^__(END|DATA)__\s*$/) {
  $_ = "\n";
  return 0;
  }

Double-oddly, it doesn't occur on perl 5.005_63+ for OS/2. Detailed
version information is included.

-- Rocco Caputo / troc@​netrus.net

unix​:/usr/home/troc/perl/xws$ perl -V
Summary of my perl5 (revision 5.0 version 5 subversion 61) configuration​:
  Platform​:
  osname=freebsd, osvers=3.1-stable, archname=i386-freebsd-thread
  uname='freebsd unix.homenet 3.1-stable freebsd 3.1-stable #14​: fri may 28 13​:58​:18 edt 1999 troc@​unix.homenet​:usrsrcsyscompilecustom i386 '
  config_args='-Dusethreads'
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=define useperlio=undef d_sfio=undef
  use64bits=undef usemultiplicity=undef
  Compiler​:
  cc='cc', optimize='-O2 -g', gccversion=2.7.2.1
  cppflags='-DDEBUGGING -I/usr/local/include'
  ccflags ='-DDEBUGGING -I/usr/local/include'
  stdchar='char', d_stdstdio=undef, usevfork=true
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
  alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags ='-pthread -Wl,-E -L/usr/local/lib'
  libpth=/usr/lib /usr/local/lib
  libs=-lm -lc_r -lcrypt
  libc=, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
  cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl)​:
  Compile-time options​: DEBUGGING
  Built under freebsd
  Compiled at Sep 6 1999 14​:15​:58
  @​INC​:
  /usr/local/perl5.005_61/lib/i386-freebsd-thread
  /usr/local/perl5.005_61/lib
  /usr/local/perl5.005_61/lib/site_perl/i386-freebsd-thread
  /usr/local/perl5.005_61/lib/site_perl
  .

[d​:\home\troc>perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 53) configuration​:
  Platform​:
  osname=os2, osvers=2.30, archname=os2
  uname='os2 karetnikova 2 2.30 i386 '
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef useperlio=undef d_sfio=undef
  Compiler​:
  cc='gcc', optimize='-O2 -fomit-frame-pointer -malign-loops=2 -malign-jumps=2 -malign-functions=2 -s', gccversion=2.7.2.1
  cppflags='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I.'
  ccflags ='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I.'
  stdchar='char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
  alignbytes=4, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='gcc', ldflags ='-Zexe -Zomf -Zmt -Zcrtdll -Zstack 32000'
  libpth=d​:/usr/local/lib d​:/emx/lib d​:/emx/lib/mt
  libs=-lsocket -lm -lbsd
  libc=d​:/emx/lib/mt/c_import.lib, so=dll, useshrplib=true, libperl=libperl.lib
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
  cccdlflags='-Zdll', lddlflags='-Zdll -Zomf -Zmt -Zcrtdll -s'

Characteristics of this binary (from libperl)​:
  Built under os2
  Compiled at Nov 12 1998 23​:44​:28
  %ENV​:
  PERL5LIB="d​:/usr/local/lib/perl5;d​:\usr\lib\perl5\site_lib/os2;d​:\usr\lib\perl5\site_lib"
  PERLLIB_PREFIX="F​:/perllib/lib;D​:\USR\LIB\PERL5"
  PERL_SH_DIR="D​:\BIN"
  @​INC​:
  d​:/usr/local/lib/perl5
  d​:\usr\lib\perl5\site_lib/os2
  d​:\usr\lib\perl5\site_lib
  D​:/USR/LIB/PERL5/5.00553/os2
  D​:/USR/LIB/PERL5/5.00553
  D​:/USR/LIB/PERL5/site_perl/5.00553/os2
  D​:/USR/LIB/PERL5/site_perl/5.00553
  .

[p5pRT]

From @pmqs

From​: Rocco Caputo [mailto​:troc@​netrus.net]

On Sun, 26 Mar 2000 22​:26​:58 +0100, Marquess,P,Paul,NEL38 R wrote​:

I can't reproduce the __END__/__DATA__ problem on my Linux box at all
(Mandrake 6.1), but I've removed the use of IoFLAGS anyway. I don't think
I
need to set the IOf_FAKE_DIRP flag in the filters myself because toke.c
takes care of it. I've also added a couple of tests to check that __END__
&
__DATA__ will work with Call.pm

This patch applies over a fresh copy of Filter-1.17. As well as the
__(END|DATA)__ problem, it includes Sarathy's threading patch. If it
works
for those folk who were having the __(END|DATA)__ problems, I'll upload
it
to CPAN.

Paul

The problem happens on my FreeBSD machine, even with your attached
patches.
Oddly, I've found a work-around​: simply don't allow the __(END|DATA)__
line to be parsed​:

# Treat it as EOF.
if (/^__(END|DATA)__\s*$/) {
$_ = "\n";
return 0;
}

The workaround will work most of the time. It would be difficult to do get
right all the time

  $a = <<EOM ;

  hello
  __END__
  EOM

  print $a ;

Double-oddly, it doesn't occur on perl 5.005_63+ for OS/2. Detailed
version information is included.

Hmmm, I think this may be due to IOf_FAKE_DIRP being a recent addition to
Perl. Seems to have been added in 5.005_63.

Do you have a 5.6.0 about to try a before and after test?

Paul

[p5pRT]

From [Unknown Contact. See original ticket]

On Mon, 27 Mar 2000 13​:34​:50 +0100, paul.marquess@​bt.com wrote​:

From​: Rocco Caputo [mailto​:troc@​netrus.net]

On Sun, 26 Mar 2000 22​:26​:58 +0100, Marquess,P,Paul,NEL38 R wrote​:

This patch applies over a fresh copy of Filter-1.17. As well as the
__(END|DATA)__ problem, it includes Sarathy's threading patch. If it works
for those folk who were having the __(END|DATA)__ problems, I'll upload it
to CPAN.

Paul

The problem happens on my FreeBSD machine, even with your attached patches.
Oddly, I've found a work-around​: simply don't allow the __(END|DATA)__
line to be parsed​:

# Treat it as EOF.
if (/^__(END|DATA)__\s*$/) {
$_ = "\n";
return 0;
}

The workaround will work most of the time. It would be difficult to do get
right all the time

$a = <<EOM ;

hello
__END__
EOM

print $a ;

True, true. I'm currently the target audience for the POE​::Preprocessor
module, so I've apprised myself of its caveats and promised myself a fix
should I ever need one. As Programmer Barbie says, "Parsing Perl is
*hard*!" :)

Double-oddly, it doesn't occur on perl 5.005_63+ for OS/2. Detailed
version information is included.

Hmmm, I think this may be due to IOf_FAKE_DIRP being a recent addition to
Perl. Seems to have been added in 5.005_63.

Do you have a 5.6.0 about to try a before and after test?

I don't, sorry, but I can test it on 5.005_63.

Paul

-- Rocco Caputo / troc@​netrus.net

[p5pRT]

perl.org@triv.org - Status changed from 'open' to 'resolved'