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

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

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

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About