Closed p5pRT closed 21 years ago
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
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
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
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
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@​?NEZ[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>U%U4TDXS$%3O9W
M*7`^ACM(U-/KF1&7YOL7\
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 .
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
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
perl.org@triv.org - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#2717 (status was 'resolved')
Searchable as RT2717$