JIT breaks on feather3
mark at glines.org
Wed Dec 3 06:27:15 UTC 2008
Tene++ has been having some issues recently with polyglotbot, the
evalbot in #parrot IRC. I spent some time today trying to track this down.
The symptoms of this are really weird. The segfault seems to happen in
Tene's parrot checkouts, when the user is running it inside of a screen
session. It doesn't seem to crash in my own parrot checkouts, and it
doesn't crash in a bare (non-screen) ssh connection.
With the help of tewk++, we discovered that the segfault occurs as soon
as some JIT code is executed. After some more digging, it looks like
the heap does not have the executable bit set.
Parrot's /proc/<pid>/maps contains this when run under screen:
0804f000-08437000 rw-p 0804f000 00:00 0 [heap]
And this when run outside of screen:
0804f000-08322000 rwxp 0804f000 00:00 0 [heap]
That's for the same binary, executed by the same user, from the same
working directory, with the same arguments.
Its not clear yet what is causing the heap to not have the executable
bit set. It's really troublesome to reproduce this - I haven't seen it
anywhere else, and it only occurs under a few circumstances (feather3,
tene's homedir, running under screen) that don't really make sense
together yet. But in any case, whatever is causing this, it breaks JIT
Kevin mentioned that parrot is using mprotect() to explicitly ask glibc
to make this memory executable. Since it isn't, that possibly makes
this a glibc bug. Either way, this seems like the sort of issue which
would keep cropping up in weird ways, unless we could detect/prevent it
So, List, does anyone happen to know why processes under screen have
non-executable stacks? Or possibly a bash shopt or ulimit or dropped
privilege or somesuch?
More information about the parrot-dev