p5pRT
commented
24 years ago 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
Migrated from rt.perl.org#2717 (status was 'resolved')
Searchable as RT2717$