develooper Front page | perl.perl5.porters | Postings from March 2000

[ID 20000325.008] 5.6, source filters, modules, and __END__ go boom

Thread Next
Nathan Torkington
March 25, 2000 22:19
[ID 20000325.008] 5.6, source filters, modules, and __END__ go boom
Message ID:
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;

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


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

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/
#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


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About