JIT breaks on feather3

[Geoffrey Broadwell]

On Wed, 2008-12-03 at 06:40 -0800, Mark Glines wrote:
> 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.

Perhaps some security option is being set based on not having a "real"
tty?

> 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.

That's a pretty old kernel (from the previous stable release).  My
Debian lenny/sid system reports a 2.6.26 kernel, and according to
apt-cache linux-image-2.6-xen-686 is up to 2.6.26+16.  I'm not sure it
makes a big difference, but Xen is developed fairly rapidly so there
might be fixes to memory protection bits in between 2.6.18 and 2.6.26.


-'f