Messages in this thread | | | Subject | Re: [PATCH] mm: larger stack guard gap, between vmas | From | Ben Hutchings <> | Date | Wed, 05 Jul 2017 00:01:55 +0100 |
| |
On Tue, 2017-07-04 at 12:36 +0100, Ben Hutchings wrote: [...] > This *doesn't* fix the LibreOffice regression on i386.
gdb shows me that the crash is at the last statement in this function:
static void _expand_stack_to(address bottom) { address sp; size_t size; volatile char *p;
// Adjust bottom to point to the largest address within the same page, it // gives us a one-page buffer if alloca() allocates slightly more memory. bottom = (address)align_size_down((uintptr_t)bottom, os::Linux::page_size()); bottom += os::Linux::page_size() - 1;
// sp might be slightly above current stack pointer; if that's the case, we // will alloca() a little more space than necessary, which is OK. Don't use // os::current_stack_pointer(), as its result can be slightly below current // stack pointer, causing us to not alloca enough to reach "bottom". sp = (address)&sp;
if (sp > bottom) { size = sp - bottom; p = (volatile char *)alloca(size); assert(p != NULL && p <= (volatile char *)bottom, "alloca problem?"); p[0] = '\0'; } }
We have:
bottom = 0xff803fff sp = 0xffffb178
The relevant mappings are:
ff7fc000-ff7fd000 rwxp 00000000 00:00 0 fffdd000-ffffe000 rw-p 00000000 00:00 0 [stack]
So instead of a useless guard page, we have a dangerous WX page underneath the stack! I suppose I should find out where and why that's being allocated.
Ben.
-- Ben Hutchings The world is coming to an end. Please log off. [unhandled content-type:application/pgp-signature] | |