Red Hat Bugzilla – Bug 499304
Parrot segfaults when trying to run the PGE grammer
Last modified: 2009-11-18 09:23:28 EST
Created attachment 342583 [details]
grammer file 1
Description of problem:
Segfault when running the Perl6Grammer.pbc
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. build basic language shell (using mk_language_shell.pl script from source tarball)
2. run make
- or -
1. download two attached grammer files
2. run the following
it to generate the PIR output file
Tested on two 32-bit Fedora 10 systems with same results
Created attachment 342584 [details]
grammer file 2
#0 0x0085b0e1 in Parrot_NCI_invoke (interp=0x8050040, pmc=0x80e2208, next=0x0) at src/pmc/nci.pmc:320
#1 0x00745eaa in Parrot_pcc_invoke_from_sig_object (interp=0x8050040, sub_obj=0x80e2208, sig_obj=0x81f9b90)
#2 0x00752867 in Parrot_mmd_multi_dispatch_from_c_args (interp=0x8050040, name=0x9680c9 "cmp", sig=0x979116 "PP->I")
#3 0x0082abdc in Parrot_default_cmp (interp=0x8050040, pmc=0x8050040, value=0xb7fdfd98) at src/pmc/default.pmc:2439
#4 0x006f9fab in Parrot_lt_p_ic_ic (cur_opcode=0xb726265c, interp=0x8050040) at src/ops/cmp.ops:299
#5 0x00777492 in runops_slow_core (interp=0x8050040, pc=0xb726265c) at src/runops_cores.c:461
#6 0x0074a81f in runops_int (interp=0x8050040, offset=562) at src/interpreter.c:980
#7 0x0074b3b2 in runops (interp=0x8050040, offs=562) at src/call/ops.c:107
#8 0x0074b52d in runops_args (interp=0x8050040, sub=0x80f0938, obj=0x8155578, meth_unused=0x807b190,
sig=0x972f33 "S", ap=0xbffff304 "##########sm") at src/call/ops.c:254
#9 0x0074ba72 in Parrot_run_meth_fromc_args (interp=0x8050040, sub=0x80f0938, obj=0x8155578, meth=0x807b190,
sig=0x972f33 "S") at src/call/ops.c:461
#10 0x008f75e4 in Parrot_Object_get_string (interp=0x8050040, pmc=0x8155578) at src/pmc/object.c:2994
#11 0x006e4b26 in Parrot_set_s_p (cur_opcode=0xb72683b4, interp=0x8050040) at src/ops/set.ops:148
#12 0x00777492 in runops_slow_core (interp=0x8050040, pc=0xb72683b4) at src/runops_cores.c:461
#13 0x0074a81f in runops_int (interp=0x8050040, offset=22) at src/interpreter.c:980
#14 0x0074b3b2 in runops (interp=0x8050040, offs=22) at src/call/ops.c:107
#15 0x0074b52d in runops_args (interp=0x8050040, sub=0x80f2420, obj=0x80b1358, meth_unused=0x0, sig=0x967960 "P",
ap=0xbffff48c "x#### at src/call/ops.c:254
#16 0x0074bce8 in Parrot_runops_fromc_args (interp=0x8050040, sub=0x80f2420, sig=0x967960 "P") at src/call/ops.c:321
#17 0x00772c4a in run_sub (interp=0x8050040, sub_pmc=0x8050040) at src/packfile.c:663
#18 0x00772e9a in do_1_sub_pragma () at src/packfile.c:754
---Type <return> to continue, or q <return> to quit---
#19 do_sub_pragmas (interp=0x8050040, self=0x8112a98, action=PBC_MAIN, eval_pmc=0x0) at src/packfile.c:893
#20 0x007730b2 in PackFile_fixup_subs (interp=0x8050040, what=PBC_MAIN, eval=0x0) at src/packfile.c:4697
#21 0x009553d1 in imcc_run_pbc () at compilers/imcc/main.c:796
#22 imcc_run (interp=0x8050040, sourcefile=0xbffff7a2 "/usr/lib/parrot/1.0.0/library/PGE/Perl6Grammar.pbc", argc=4,
argv=0xbffff640) at compilers/imcc/main.c:1085
#23 0x080488a5 in main (argc=4, argv=0xbffff640) at src/main.c:61
This week I am to busy to reproduce this problem.
If that's what I think it is, this particular bug has been showing up a
lot from Fedora users. It seems Fedora uses selinux with a
configuration more strict than most; it doesn't like that our JIT
buffers are both writable and executable, so it disables the exec bit
and causes a segfault when we try to execute it. Another fedora user
(this one was building parrot from source) has told us that setting
selinux to "permissive" mode allows parrot to work. See
If this is the issue, there are a couple of other possible workarounds:
* Disable selinux in /etc/sysconfig/selinux
* Adding an selinux exception for parrot, if possible (the JVM may have
a similar exception)
Would you check it please. If it is so, I will try to build a better RPM that
has no problems with selinux.
I'm not sure if it's selinux that's preventing it from running. As I have selinux in permissive mode on both systems. and I see no log entries for selinux violations related to parrot.
However, (your explanation of the JIT buffer block helped greatly), the kernel Exec Shield is what is stopping it.
If I do this as root
sysctl -w kernel.exec-shield=0
And then re-run the parrot command, everything works as expected.
And ass I don't really want to disable exec-shield, there has to be another way to fix this. From the bug report your linked to on parrot's trac install someone posted something about 4 hours ago that mentions that possibly the build is not correctly detecting that "exec shield" is enabled on the OS and need s to be taken into account.
I am on a journey until Tuesday. I will look after Wednesday at this.
Under the URL
is a workaround, that configuring Parrot with --jitcapable=0
The URL special for the i386 buildArch is:
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
This seems to be fixed in the current release as I don't recall it crashing any longer in F11