Mailinglist Archive: opensuse-bugs (4644 mails)

< Previous Next >
[Bug 1045340] regression: java segfaults on latest kernels caused by the stack gap fix
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Thu, 22 Jun 2017 11:05:57 +0000
  • Message-id: <>

--- Comment #20 from Michal Hocko <mhocko@xxxxxxxx> ---
(In reply to Vlastimil Babka from comment #19)
(In reply to Michal Hocko from comment #18)
(In reply to Vlastimil Babka from comment #10)
(In reply to Vlastimil Babka from comment #9)
Catchpoint 1 (call to syscall mmap2), 0xf7fd9f89 in __kernel_vsyscall ()

(gdb) bt
#0 0xf7fd9f89 in __kernel_vsyscall ()
#1 0xf7454508 in mmap () from /lib/
#2 0xf7a51cdb in os::commit_memory(char*, unsigned int, bool) () from

OK, this is what I found in jdk source
// NOTE: Linux kernel does not really reserve the pages for us.
// All it does is to check if there are enough free pages
// left at the time of mmap(). This could be a potential
// problem.

Um, did they hear about MAP_POPULATE?

I am pretty sure they do not want this if they plan to use really large stacks.

bool os::commit_memory(char* addr, size_t size, bool exec) {
uintptr_t res = (uintptr_t) ::mmap(addr, size, prot,
return res != (uintptr_t) MAP_FAILED;


which explains it I am afraid. We simply smash a new mapping in the middle
of the stack. And so the stack expansion cannot possibly work. :/

Yeah, I guess they think they are placing the guards below the stack, that's
why there's mmap first and then mprotect (which could be done by single mmap
with the right protection flags, but nevermind).

well, they could simply mprotect directly and mmap only if it failed.

You are receiving this mail because:
You are on the CC list for the bug.
< Previous Next >