Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rakudo segfaults calling subs in a module #156

Closed
p6rt opened this issue Jul 5, 2008 · 12 comments
Closed

rakudo segfaults calling subs in a module #156

p6rt opened this issue Jul 5, 2008 · 12 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Jul 5, 2008

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

Searchable as RT56618$

@p6rt
Copy link
Author

p6rt commented Jul 5, 2008

From @jeffhorwitz

In r29081, the following code segfaults​:

  module Foo​::Bar;
  sub foo() { say "bar"; }
  foo(); # segfaults here

The script works if the modules declaration is omitted. I also tried
running with -G, and it still segfaults at the same place. pmichaud was
able to reproduce as well.

Backtrace follows​:

#​0 0x402cc6df in Parrot_Closure_invoke (interp=0x804f048, pmc=0x4161e700,
  in_next=0x868e23c) at closure.pmc​:103
103 else if ((PObj_get_FLAGS(outer_sub) & SUB_FLAG_IS_OUTER)
&&
(gdb) bt
#​0 0x402cc6df in Parrot_Closure_invoke (interp=0x804f048, pmc=0x4161e700,
  in_next=0x868e23c) at closure.pmc​:103
#​1 0x400f32d6 in Parrot_invokecc_p (cur_opcode=0x868e234,
  interp=0x804f048)
  at core.ops​:413
#​2 0x40196274 in runops_slow_core (interp=0x804f048, pc=0x868e234)
  at src/runops_cores.c​:221
#​3 0x40168c26 in runops_int (interp=0x804f048, offset=17)
  at src/interpreter.c​:918
#​4 0x40169525 in runops (interp=0x804f048, offs=17) at
  src/inter_run.c​:106
#​5 0x401697aa in runops_args (interp=0x804f048, sub=0x4161e754,
  obj=0x8099da8, meth_unused=0x0, sig=0x403c5814 "P",
  ap=0xbffff7bc "\005\025@​\001") at src/inter_run.c​:232
#​6 0x401698ec in Parrot_runops_fromc_args (interp=0x804f048,
  sub=0x4161e754,
  sig=0x403c5814 "P") at src/inter_run.c​:301
#​7 0x4018b8c5 in run_sub (interp=0x804f048, sub_pmc=0x4161e754)
  at src/packfile.c​:493
#​8 0x4018bb0c in do_1_sub_pragma (interp=0x804f048, sub_pmc=0x4161e754,
  action=PBC_MAIN) at src/packfile.c​:585
#​9 0x4018bda6 in do_sub_pragmas (interp=0x804f048, self=0x87c4938,
  action=PBC_MAIN, eval_pmc=0x4161e540) at src/packfile.c​:719
#​10 0x401903c5 in PackFile_fixup_subs (interp=0x804f048, what=PBC_MAIN,
  eval=0x4161e540) at src/packfile.c​:3800
#​11 0x403aeea0 in imcc_compile (interp=0x804f048,
  s=0x87c4508 "\n.namespace \n.sub \"_block11\" :lexid(\"21\")\n new
  $P12, \"Perl6Scalar\"\n .lex \"$_\", $P12\n new $P13,
  \"Perl6Scalar\"\n .lex \"$!\", $P13\n new $P14, \"Perl6Scalar\"\n
  .lex \"$/\", $P14\n get_hll_g"..., pasm_file=0,
  error_message=0xbffff94c)
  at compilers/imcc/parser_util.c​:920
#​12 0x403af143 in imcc_compile_pir_ex (interp=0x804f048,
  s=0x87c4508 "\n.namespace \n.sub \"_block11\" :lexid(\"21\")\n new
  $P12, \"Perl6Scalar\"\n .lex \"$_\", $P12\n new $P13,
  \"Perl6Scalar\"\n .lex \"$!\", $P13\n new $P14, \"Perl6Scalar\"\n
  .lex \"$/\", $P14\n get_hll_g"...)
  atcompilers/imcc/parser_util.c​:1086
#​13 0x4017261d in pcf_P_Jt (interp=0x804f048, self=0x82238e8) at
  src/nci.c​:234
#​14 0x402d6c9e in Parrot_NCI_invoke (interp=0x804f048, pmc=0x82238e8,
  next=0x412c8ce8) at nci.pmc​:203
#​15 0x400f32d6 in Parrot_invokecc_p (cur_opcode=0x412c8ce0, interp=0x804f048)
  at core.ops​:413
#​16 0x40196274 in runops_slow_core (interp=0x804f048, pc=0x412c8ce0)
  at src/runops_cores.c​:221
#​17 0x40168c26 in runops_int (interp=0x804f048, offset=3280)
  at src/interpreter.c​:918
#​18 0x40169525 in runops (interp=0x804f048, offs=13293) at
  src/inter_run.c​:106
#​19 0x401697aa in runops_args (interp=0x804f048, sub=0x8354d00,
  obj=0x8099da8,
  meth_unused=0x0, sig=0x403c1d47 "vP", ap=0xbffffbbc "P\035A\220")
  at src/inter_run.c​:232
#​20 0x401698ec in Parrot_runops_fromc_args (interp=0x804f048,
  sub=0x8354d00,
  sig=0x403c1d47 "vP") at src/inter_run.c​:301
#​21 0x40152507 in Parrot_runcode (interp=0x804f048, argc=2,
  argv=0xbffffd1c)
  at src/embed.c​:950
#​22 0x4039d334 in imcc_run_pbc (interp=0x804f048, obj_file=0,
  output_file=0x0,
  argc=2, argv=0xbffffd1c) at compilers/imcc/main.c​:782
#​23 0x4039dde2 in imcc_run (interp=0x804f048,
  sourcefile=0xbffffe20 "perl6.pbc", argc=2, argv=0xbffffd1c)
  at compilers/imcc/main.c​:1070
#​24 0x080488d8 in main (argc=2, argv=0xbffffd1c) at src/main.c​:61

@p6rt
Copy link
Author

p6rt commented Jul 5, 2008

From @chromatic

On Saturday 05 July 2008 09​:42​:33 Jeff Horwitz wrote​:

In r29081, the following code segfaults​:

module Foo​::Bar;
sub foo() { say "bar"; }
foo(); # segfaults here

The script works if the modules declaration is omitted. I also tried
running with -G, and it still segfaults at the same place. pmichaud was
able to reproduce as well.

Backtrace follows​:

#​0 0x402cc6df in Parrot_Closure_invoke (interp=0x804f048, pmc=0x4161e700,
in_next=0x868e23c) at closure.pmc​:103
103 else if ((PObj_get_FLAGS(outer_sub) & SUB_FLAG_IS_OUTER)
&&

Random guess​: foo() is a Closure PMC, but it doesn't have an outer. Aren't
all Subs generated from Rakudo Closures at the moment?

-- c

@p6rt
Copy link
Author

p6rt commented Jul 5, 2008

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Jul 6, 2008

From @pmichaud

On Sat, Jul 05, 2008 at 01​:03​:20PM -0700, chromatic wrote​:

On Saturday 05 July 2008 09​:42​:33 Jeff Horwitz wrote​:

In r29081, the following code segfaults​:

module Foo​::Bar;
sub foo() { say "bar"; }
foo(); # segfaults here

The script works if the modules declaration is omitted. I also tried
running with -G, and it still segfaults at the same place. pmichaud was
able to reproduce as well.

Backtrace follows​:

#​0 0x402cc6df in Parrot_Closure_invoke (interp=0x804f048, pmc=0x4161e700,
in_next=0x868e23c) at closure.pmc​:103
103 else if ((PObj_get_FLAGS(outer_sub) & SUB_FLAG_IS_OUTER)
&&

Random guess​: foo() is a Closure PMC, but it doesn't have an outer. Aren't
all Subs generated from Rakudo Closures at the moment?

Good guess -- you're likely correct. This is a convergence of issues --
first, Rakudo is now tagging all of its subs with an :instanceof attribute,
which automatically makes every sub into a subclass of the Closure PMC.
However, as noted in RT #​47956 subs with :load cannot be the target of :outer,
and so we end up with a Closure PMC that has no :outer flag (bad), and thus
the segfault (also bad).

Allison has said that RT #​47956 is fixed in the pdd25cx branch, so that may
be one solution. However, I also know that we need a better solution to
:instanceof than we have implemented now, so that may be another. Beyond that,
I'm not sure what we can do for the very short term. My guess is that we
may need to avoid :instanceof in Rakudo for the time being, since it's more
important that we get modules and classes to work than it is to have imcc
create subs of the appropriate type.

Thanks!

Pm

@p6rt
Copy link
Author

p6rt commented Jul 6, 2008

From @jnthn

Patrick R. Michaud wrote​:

However, I also know that we need a better solution to :instanceof than we have implemented now, so that may be another. Beyond that, I'm not sure what we can do for the very short term. My guess is that we
may need to avoid :instanceof in Rakudo for the time being, since it's more important that we get modules and classes to work than it is to have imcc create subs of the appropriate type.

I have a patch that gets us off using :instanceof mostly ready; I'll get
it finished up and checked in on my Rakudo day (Tuesday, I expect).

Thanks,

Jonathan

@p6rt
Copy link
Author

p6rt commented Jul 6, 2008

From @pmichaud

On Sun, Jul 06, 2008 at 03​:58​:45PM +0200, Jonathan Worthington wrote​:

Patrick R. Michaud wrote​:

However, I also know that we need a better solution to :instanceof than we
have implemented now, so that may be another. Beyond that, I'm not sure
what we can do for the very short term. My guess is that we
may need to avoid :instanceof in Rakudo for the time being, since it's
more important that we get modules and classes to work than it is to have
imcc create subs of the appropriate type.

I have a patch that gets us off using :instanceof mostly ready; I'll get
it finished up and checked in on my Rakudo day (Tuesday, I expect).

Would it hurt for us to temporarily remove :instanceof from
src/parser/actions.pm (at least for subs) until your patch is
ready? Otherwise "module Foo;" doesn't really work -- e.g., for mod_perl6.

Thanks!

Pm

@p6rt
Copy link
Author

p6rt commented Jul 6, 2008

From @jnthn

Patrick R. Michaud wrote​:

Would it hurt for us to temporarily remove :instanceof from
src/parser/actions.pm (at least for subs) until your patch is
ready? Otherwise "module Foo;" doesn't really work -- e.g., for mod_perl6.

If you're ready for two spectests that currently pass to start failing,
you can do that. On the other hand, my patch causes the exact same
failures and but replaces :instanceof with something useful, so if we
can put up with that regression for a few days I may as well just put my
patch in today as it is anyway. (Trying to get some hacking break
today...RSI is going to bite me next week otherwise. Thus why I'd rather
not try and fix it all up today.)

Thanks,

Jonathan

@p6rt
Copy link
Author

p6rt commented Jul 6, 2008

From @pmichaud

On Sun, Jul 06, 2008 at 04​:11​:53PM +0200, Jonathan Worthington wrote​:

Patrick R. Michaud wrote​:

Would it hurt for us to temporarily remove :instanceof from
src/parser/actions.pm (at least for subs) until your patch is
ready? Otherwise "module Foo;" doesn't really work -- e.g., for mod_perl6.

If you're ready for two spectests that currently pass to start failing,
you can do that. On the other hand, my patch causes the exact same
failures and but replaces :instanceof with something useful, so if we
can put up with that regression for a few days I may as well just put my
patch in today as it is anyway. (Trying to get some hacking break
today...RSI is going to bite me next week otherwise. Thus why I'd rather
not try and fix it all up today.)

I don't mind having a couple of regression failures for a day or two.
We could also "todo/skip" the newly failing spectests until the full
patch is available, to avoid confusion for others who may be running
spectest_regression.

Pm

@p6rt
Copy link
Author

p6rt commented Jul 6, 2008

From @jnthn

Patrick R. Michaud wrote​:

I don't mind having a couple of regression failures for a day or two.

OK, then it's in as r29098.

Thanks,

Jonathan

@p6rt
Copy link
Author

p6rt commented Jul 6, 2008

From @jeffhorwitz

On Sun, 6 Jul 2008, Jonathan Worthington via RT wrote​:

Patrick R. Michaud wrote​:

I don't mind having a couple of regression failures for a day or two.

OK, then it's in as r29098.

excellent, this fixes my problem. do we want to close out this ticket and
let RT #​47956 handle the rest, or are there still some lingering issues to
address with :instanceof?

-jeff

@p6rt
Copy link
Author

p6rt commented Aug 7, 2008

From @jnthn

On Sun Jul 06 10​:13​:15 2008, jhorwitz wrote​:

excellent, this fixes my problem. do we want to close out this ticket
and
let RT #​47956 handle the rest, or are there still some lingering
issues to
address with :instanceof?

Maybe, but we're not using it for the moment and there's some larger
design discussions to be had around this stuff. So I think we can close
this ticket now the issue it reports is resolved, and any :instanceof
issues can have tickets of their own.

Thanks,

Jonathan

@p6rt
Copy link
Author

p6rt commented Aug 7, 2008

@jnthn - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Aug 7, 2008
@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant