On Mon, 2003-11-17 at 20:12, Roland McGrath wrote:
> The official binary of mit-scheme 7.7.1
> segfaults if called with 'scheme -compiler'. In this case the scheme main
> program load a 'band' called compiler.com
, which contains executable code.
> Could somebody investigate this issue? I am not that familiar with problems
> like this.
If this binary was created with old tools and has no PT_GNU_STACK marker,
then it should get executable stack by default. More likely the issue is
that it calls malloc and expects the memory returned to be executable.
The Scheme runtime needs to be changed to use mmap when executability matters.
I further investigated problem using scheme-7.7.90 and found the
following. When loading a band (the runtime image), the following is
static void *
mmap_heap_malloc_1 (unsigned long requested_length, int fixedp)
unsigned long ps = (UX_getpagesize ());
void * addr
= (mmap (((void *) MMAP_BASE_ADDRESS),
(((requested_length + (ps - 1)) / ps) * ps),
(PROT_EXEC | PROT_READ | PROT_WRITE),
(MAP_PRIVATE | MAP_ANONYMOUS | (fixedp ? MAP_FIXED : 0)),
/* Ignored by GNU/Linux, required by FreeBSD and Solaris. */
return ((addr == MAP_FAILED) ? 0 : addr);
Now for the default runtime (runtime.com
), requested_length == 5726028,
and the function proceeds without fault. However when the "-compiler"
switch is used to load the compiler, the all.com
runtime is loaded and
then requested_length == 18563072 (this image is much bigger) and the
mmap call results in a segfault. ps is 4096, fixedp is 1 and
MMAP_BASE_ADDRESS == 4096.
Why does mmap segfault at all? Shouldn't it at worst return an error?
Hope this helps...