[Bug 1045340] New: groupwise segfaults on kernel-default-4.4.72-18.12.2
http://bugzilla.suse.com/show_bug.cgi?id=1045340 Bug ID: 1045340 Summary: groupwise segfaults on kernel-default-4.4.72-18.12.2 Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: openSUSE 42.2 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-maintainers@forge.provo.novell.com Reporter: astieger@suse.com QA Contact: qa-bugs@suse.de CC: meissner@suse.com Found By: Community User Blocker: --- groupwise segfaults on kernel-default-4.4.72-18.12.2. On 4.4.70-18.9-default it works. Merely booting between the kernels exposes the behavior. novell-groupwise-gwcheck-8.0.2-90840.i586 novell-groupwise-client-8.0.2-90840.i586 Thread 1 "groupwise-bin" received signal SIGSEGV, Segmentation fault. 0xf52ae3d6 in ?? () (gdb) backtrace #0 0xf52ae3d6 in ?? () #1 0xf52a7fcd in ?? () #2 0xf52a52cc in ?? () #3 0xf792e840 in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #4 0xf7a54298 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #5 0xf792e69f in JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #6 0xf790ae96 in instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #7 0xf7909c21 in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #8 0xf7909168 in instanceKlass::initialize(Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #9 0xf7923926 in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #10 0xf52b56c4 in ?? () #11 0xf52a7fcd in ?? () #12 0xf52a52cc in ?? () #13 0xf792e840 in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #14 0xf7a54298 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #15 0xf792e69f in JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #16 0xf790ae96 in instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #17 0xf7909c21 in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #18 0xf7909168 in instanceKlass::initialize(Thread*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #19 0xf7aff953 in Threads::create_vm(JavaVMInitArgs*, bool*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #20 0xf7960566 in JNI_CreateJavaVM () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #21 0x08048dc3 in LaunchJavaVm (argc=0, argv=0xffffcf68, szPathToClientDir=0xffffcaa8 "/opt/novell/groupwise/client") at grpwisex.cpp:380 #22 0x080497a3 in main (argc=1, argv=0xffffcf64) at grpwisex.cpp:47 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Marcus Meissner
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Marcus Meissner
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Marcus Meissner
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Jiri Kosina
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Jiri Kosina
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c1
Jiri Kosina
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c2
--- Comment #2 from Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c3
--- Comment #3 from Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c4
--- Comment #4 from Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c6
--- Comment #6 from Vlastimil Babka
Just installed novell-groupwise-gwclient.rpm from IBS, and update to 4.4.72 kernel.
How exactly can I get the rpm? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c8
--- Comment #8 from Vlastimil Babka
(In reply to Vlastimil Babka from comment #6)
How exactly can I get the rpm?
I am using:
https://gwclient.innerweb.novell.com/ https://gwclient.innerweb.novell.com/client/gw802linuxclient.tar.gz
Thanks. I've run it under gdb and when it segfaulted, checked the /proc/pid/smaps: ffedd000-fffae000 rwxp 00000000 00:00 0 (this is without the gap) Size: 1860 kB (the size however includes gap) ... VmFlags: rd wr ex mr mw me gd ac (gd == grows down - a stack) fffae000-fffb1000 ---p 00000000 00:00 0 (not r/w/x) Size: 12 kB ... VmFlags: mr mw me ac sd (doesn't have gd) 1000b1000-ffffe000 rwxp 00000000 00:00 0 (invalid reported start addr as it adds the full gap size to real vma start) [stack] Size: 308 kB (real size without gap: fffb1000-ffffe000) Rss: 24 kB (we have used only this much stack yet) Pss: 24 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 24 kB Referenced: 24 kB Anonymous: 24 kB AnonHugePages: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd wr ex mr mw me gd ac (again grows down) Looks like the same issue as I've seen with jsvc reproducer from debian bugzilla, that we discussed via mail. The original stack ffedd000-ffffe000 was split by mprotecting the area ffedd000-fffae000 inside the stack. The remaining "upper part" fffb1000-ffffe000 is now smaller than stack gap, and preceding vma is not a stack, so faulting a new page in the upper part (where we only have faulted in 24 kB so far) will find this out and fail to enlarge the gap, thus segfault. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c9
--- Comment #9 from Vlastimil Babka
(In reply to Andreas Stieger from comment #7)
(In reply to Vlastimil Babka from comment #6)
How exactly can I get the rpm?
I am using:
https://gwclient.innerweb.novell.com/ https://gwclient.innerweb.novell.com/client/gw802linuxclient.tar.gz
Thanks. I've run it under gdb and when it segfaulted, checked the /proc/pid/smaps:
And also managed to catch the mmap+mprotect syscalls responsible for the vma split. No idea why these addresses are not visible in the strace log, though... Catchpoint 1 (call to syscall mmap2), 0xf7fd9f89 in __kernel_vsyscall () (gdb) info registers eax 0xffffffda -38 ecx 0x3000 12288 edx 0x3 3 ebx 0xfffae000 -335872 esp 0xffffbd5c 0xffffbd5c ebp 0x0 0x0 esi 0x32 50 edi 0xffffffff -1 eip 0xf7fd9f89 0xf7fd9f89 <__kernel_vsyscall+9> eflags 0x246 [ PF ZF IF ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x63 99 (gdb) c Continuing. Catchpoint 1 (returned from syscall mmap2), 0xf7fd9f89 in __kernel_vsyscall () (gdb) c Continuing. Catchpoint 2 (call to syscall mprotect), 0xf7fd9f89 in __kernel_vsyscall () (gdb) info reg eax 0xffffffda -38 ecx 0x3000 12288 edx 0x0 0 ebx 0xfffae000 -335872 esp 0xffffbd78 0xffffbd78 ebp 0xffffbda8 0xffffbda8 esi 0xfffae000 -335872 edi 0x8054800 134563840 eip 0xf7fd9f89 0xf7fd9f89 <__kernel_vsyscall+9> eflags 0x246 [ PF ZF IF ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x63 99 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c10
--- Comment #10 from Vlastimil Babka
Catchpoint 1 (call to syscall mmap2), 0xf7fd9f89 in __kernel_vsyscall ()
(gdb) bt #0 0xf7fd9f89 in __kernel_vsyscall () #1 0xf7454508 in mmap () from /lib/libc.so.6 #2 0xf7a51cdb in os::commit_memory(char*, unsigned int, bool) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #3 0xf7afd1be in JavaThread::create_stack_guard_pages() () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #4 0xf7afedd3 in Threads::create_vm(JavaVMInitArgs*, bool*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #5 0xf7960566 in JNI_CreateJavaVM () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #6 0x08048dc3 in LaunchJavaVm (argc=0, argv=0xffffd528, szPathToClientDir=0xffffd068 "/opt/novell/groupwise/client") at grpwisex.cpp:380 #7 0x080497a3 in main (argc=1, argv=0xffffd524) at grpwisex.cpp:473
Catchpoint 2 (call to syscall mprotect), 0xf7fd9f89 in __kernel_vsyscall () (gdb) bt #0 0xf7fd9f89 in __kernel_vsyscall () #1 0xf74545f9 in mprotect () from /lib/libc.so.6 #2 0xf7a525b9 in os::guard_memory(char*, unsigned int) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #3 0xf7afd1e2 in JavaThread::create_stack_guard_pages() () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #4 0xf7afedd3 in Threads::create_vm(JavaVMInitArgs*, bool*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #5 0xf7960566 in JNI_CreateJavaVM () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so #6 0x08048dc3 in LaunchJavaVm (argc=0, argv=0xffffd528, szPathToClientDir=0xffffd068 "/opt/novell/groupwise/client") at grpwisex.cpp:380 #7 0x080497a3 in main (argc=1, argv=0xffffd524) at grpwisex.cpp:473
At least we see it's done by java itself and not glibc. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c11
--- Comment #11 from Vlastimil Babka
#3 0xf7afd1e2 in JavaThread::create_stack_guard_pages() () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
Looks to me like this is intended to create guard pages from userspace for non-initial threads, which AFAIK have fixed-size stacks in pthread implementation, so probably also in java. Pthreads seem to also have guard pages controlled by pthread_attr_setguardsize(). Neither should care or have issues with the kernel's guard gap implementation or gap size, as long as the extra thread stacks are not VM_GROWSDOWN. Seems there is a bug when java VM is invoked via JNI_CreateJavaVM () from another binary (and not the java launcher), where these guard pages for extra threads are applied to the initial thread and its VM_GROWSDOWN stack, where it does have issues with the larger in-kernel gap as I analyzed above. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c14
--- Comment #14 from Michal Hocko
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c16
--- Comment #16 from Michal Hocko
Here is the backported version of the upstream patch for kernel 4.4.
It applies cleanly to the opensuse 42.2 git master: https://patchwork.kernel.org/patch/9796395/
I just had to remove: mm-enlarge-stack-guard-gap.patch mm-do-not-collapse-stack-gap-into-THP.patch
Yes we will go with the upstream version of the patch in the end. But I would like to understand what is going on here because older kernels will be more trickier to get this upstream backport. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c18
--- Comment #18 from Michal Hocko
(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/libc.so.6 #2 0xf7a51cdb in os::commit_memory(char*, unsigned int, bool) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
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. bool os::commit_memory(char* addr, size_t size, bool exec) { int prot = exec ? PROT_READ|PROT_WRITE|PROT_EXEC : PROT_READ|PROT_WRITE; uintptr_t res = (uintptr_t) ::mmap(addr, size, prot, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0); 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. :/ -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c19
--- Comment #19 from Vlastimil Babka
(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/libc.so.6 #2 0xf7a51cdb in os::commit_memory(char*, unsigned int, bool) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
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?
bool os::commit_memory(char* addr, size_t size, bool exec) { int prot = exec ? PROT_READ|PROT_WRITE|PROT_EXEC : PROT_READ|PROT_WRITE; uintptr_t res = (uintptr_t) ::mmap(addr, size, prot, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0); 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). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c20
--- Comment #20 from Michal Hocko
(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/libc.so.6 #2 0xf7a51cdb in os::commit_memory(char*, unsigned int, bool) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
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) { int prot = exec ? PROT_READ|PROT_WRITE|PROT_EXEC : PROT_READ|PROT_WRITE; uintptr_t res = (uintptr_t) ::mmap(addr, size, prot, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0); 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.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Vítězslav Čížek
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c22
--- Comment #22 from Marcus Meissner
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c24
--- Comment #24 from Michal Hocko
Created attachment 729855 [details] sk.c
From: Solar Designer
Dear Alexander, probably it is already known, otherwise please share it in oss-security@ I've noticed the problem on Red Hat kernels first, and reported to Red Hat already, but now I've found the same problem on Ubuntu kernels. It does not affect mainline patch "mm: larger stack guard gap, between vmas" but seems distributors have used some other incorrect patch (shared in linux-distros@ ??? )
Description of problem: mmap(MAP_GROUWSDOWN) works incorrectly on Red Hat and Ubuntu kernels with stackguard fix.
We have application that creates stack by using MAP_GROUWSDOWN , provide this area into clone(), where it fails on access to mapped area.
This is a different problem unrelated to this bug. In fact I would argue that we have never supported/implemented MAP_GROUWSDOWN correctly. There is only one stack that can work reliably because we place it above any mmaps or grow mmaps from lower addresses. A larger gap just makes it more obvious. Feel free to open a separate bug for this but I would tend to close it as WONTFIX. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c26
--- Comment #26 from Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c27
Jiri Kosina
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c28
--- Comment #28 from Bernhard Wiedemann
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c30
Vlastimil Babka
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c31
--- Comment #31 from Bernhard Wiedemann
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Aaron Burgemeister
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c32
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Srinidhi B S
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c34
--- Comment #34 from Marcus Meissner
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c35
--- Comment #35 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c38
--- Comment #38 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Martin Jedamzik
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c39
--- Comment #39 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c40
--- Comment #40 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Hanns-Joachim Uhl
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c41
--- Comment #41 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c42
--- Comment #42 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c43
--- Comment #43 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c44
--- Comment #44 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c45
--- Comment #45 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c46
Michael Gorse
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c47
--- Comment #47 from Michael Gorse
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c48
--- Comment #48 from Michael Gorse
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c49
--- Comment #49 from Michal Hocko
Created attachment 735042 [details] Backtrace.
Crashes when trying to write to a pointer returned by alloca.
Could you please paste /proc/pid/maps of the crashing process? Anyway we know that Java plays tricks with its own stack guard area. That should be fixed with the latest maint. update. There was another report about LO crashing on 32b http://lkml.kernel.org/r/1499126133.2707.20.camel%40decadent.org.uk with more explanation here http://lkml.kernel.org/r/1499209315.2707.29.camel@decadent.org.uk Your test program does -Xss1150k which increases the default stack size which should be 1MB on x86_64 (as per man page). Does the same happen with the default stack setup? What if you increase RLIMIT_STACK? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c50
--- Comment #50 from Michael Gorse
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c51
--- Comment #51 from Michal Hocko
Created attachment 735134 [details] maps
Thanks. Yes, looks similar to the crash described in that post.
bfedc000-bfedd000 rwxp 00000000 00:00 0 bffdf000-c0000000 rw-p 00000000 00:00 0 [stack] yes, the stupid RWX (exec shield) mapping right under the stack.
If I do not set -Xss, then I do not get a crash on startup (I'd set it in an attempt to avoid the crash, but in my case it causes one at startup).
Ulimit -s is set to 8192 for me. I tried setting it to 65536, but it doesn't make a difference.
This is interesting because I thought that the exec shield mapping is placed based on the RLIMIT somehow.
Do you know if tw should have the java update with the stack fixes? I can reproduce the same crash with 1.8 or 9.
I am not even sure there is any bug report for java... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c52
--- Comment #52 from Michael Gorse
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c53
--- Comment #53 from Michal Hocko
I'm still reading over that thread, but I wonder if it would be safe to disable that function call in openjdk--it appears to have been added as a work-around for some other bug.
yes for a feature which is long gone AFAIR. Please open a bug for java. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c54
--- Comment #54 from Michael Gorse
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c55
--- Comment #55 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1045340
Yanick Jacques
http://bugzilla.suse.com/show_bug.cgi?id=1045340
http://bugzilla.suse.com/show_bug.cgi?id=1045340#c56
Tomáš Chvátal
participants (1)
-
bugzilla_noreply@novell.com