|
From: Tom H. <to...@co...> - 2005-11-08 09:00:14
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> it seems valgrind 3.1 cannot deal anymore with executable stack requirement.
It seems to work find on my FC4 box with your test case.
> LD_LIBRARY_PATH=. valgrind --trace-syscalls=yes ./test
>
> gives:
>
> SYSCALL[671,1](125) sys_mprotect ( 0xBEE5C000, 4096, 16777223 )[sync] -->
> Failure(0x16)
> SYSCALL[671,1]( 6) sys_close ( 3 )[sync] --> Success(0x0)
> SYSCALL[671,1](146) sys_writev ( 2, 0xBEE5C3B8, 10 ) --> [async] ...
> ./test: error while loading shared libraries: libtest.so: cannot enable
> executable stack as shared object requires: Invalid argument
>
> Any idea what could be wrong? looks like the actual mprotect fails
> with a very weird way.
Well EINVAL just means there is no mapping at that address. As you
haven't posted the rest of the log we can't see if there was an early
map call that mapped that address.
Curiously I see the same failure on my box but then it carries on
instead of stopping:
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFFF000, 4096, 16777223 )[sync] --> Failure(0x16)
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFF8000, 32768, 7 )[sync] --> Failure(0xC)
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFFC000, 16384, 7 )[sync] --> Failure(0xC)
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFFE000, 8192, 7 )[sync] --> Success(0x0)
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFFC000, 8192, 7 )[sync] --> Failure(0xC)
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFFD000, 4096, 7 )[sync] --> Failure(0xC)
Actually those ENOMEM errors I am getting are far weirder... at least
they would be if you believed the mprotect manual page. Looking at the
kernel source it seems you sometimes get that if the mapping doesn't
exist though.
Actually it looks like you always get ENOMEM for that so the manual
page is complete nonsense.
The problem is that the first mprotect has PROT_GROWSDOWN set and that
causes mprotect to fail with EINVAL if the underlying VMA in the kernel
doesn't have VM_GROWSDOWN set. The normal system provided stack does
have that set, but our one doesn't and there is no way to set it from
user space as far as I know.
This isn't new in version 3 as far as I know - there are complaints
about it with older versions I think.
What PROT_GROWSDOWN does is to cause the kernel to round down the
start address given to that of the underlying VMA and apply the
protection specified to the whole area. In other words the stack
extension area also gets those permissions.
I believe that the valgrind address space manager copies the
permissions of the area being extended when extending into a
reservation so we can probably just clear PROT_GROWSUP/PROT_GROWSDOWN
when we are processing an extendable area.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|