On 01/08/2011 04:50 AM, Göran Uddeborg wrote:
It turns out the help-browser does not have any execstack flag set.
And none of the libraries involved either.
I used strace to see what actually was done, and found out that this
happens when the process tries to mmap() some anonymous memory:
17020 gettimeofday( <unfinished ...>
17020 <... gettimeofday resumed> {1294488756, 742289}, NULL) = 0
17020 mmap(NULL, 2147483648, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 <unfinished ...>
17020 <... mmap resumed> ) = -1 EACCES (Permission denied)
17020 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Looking a bit more (and repeating how to debug applications that fork
with gdb:-) I found that this is in the
/usr/lib64/libwebkitgtk-1.0.so.0, with the stack trace included below.
I don't know anything about webkitgtk, but strings such as "jit" in
that trace make me suspect that maybe this could be intentional. Now
I'm not sure what to do. Should I bug report webkitgtk.
Yes, file a bug against webkitgtk. Include the output from strace.
And if so,
is there any "right" way to do just-in-time compilation, if that is
indeed what happens? Any good pointers I could add to such a bug
report?
This works for me: allocate space first as PROT_NONE, then MAP_FIXED the
allocated space to the desired protection:
addr = mmap(0, length, PROT_NONE, MAP_PRIVATE_MAP_ANONYMOUS, -1, 0);
if (MAP_FAILED==addr) ...
addr = mmap(addr, length, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_FIXED|MAP_PRIVATE_MAP_ANONYMOUS, -1, 0);
if (MAP_FAILED==addr) ...
--