JIT breaks on feather3

[Mark Glines]

chromatic wrote:
> On Tuesday 02 December 2008 22:27:15 Mark Glines wrote:
> 
>> 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
>> somehow.
>>
>> 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?
> 
> SELinux or GCC stack protection might also do this (though I'm not *sure* of 
> the latter).

Yeah, that would make sense.  This is the heap, not the stack, but the 
same issues and motivations would apply.

The weird thing is how selective it is.  GCC stack protection should 
affect all binaries compiled with that version of GCC, but here, the 
same binary behaves in different ways depending on whether you run it 
from within screen.  That sounds crazy to me.

So it seems like something environmental.  And I did tweak %ENV so they 
were as close to identical as possible, basically everything except 
$ENV{PPID} (which is readonly for bash).  That had no effect.

If it helps, feather3 is a virtual machine running Debian lenny/sid, 
kernel 2.6.18-6-xen-686, and libc6 version 2.7-15.

Mark