On Thu, Dec 26, 2013 at 12:01 PM, Konstantin Belousov <kostikbel_at_gmail.com> wrote: > On Thu, Dec 26, 2013 at 07:51:45PM +0100, Antoine Brodin wrote: >> On Thu, Dec 26, 2013 at 7:33 PM, Peter Wemm <peter_at_wemm.org> wrote: >> > On Thu, Dec 26, 2013 at 7:39 AM, Antoine Brodin <antoine_at_freebsd.org> wrote: >> >> On Thu, Dec 26, 2013 at 1:04 PM, Andriy Gapon <avg_at_freebsd.org> wrote: >> > ... >> >> Hello, >> >> >> >> FWIW, I had a similar panic today on 9.2-RELEASE with a GENERIC kernel: >> >> panic: Bad entry start/end for new stack entry >> >> cpuid = 1 >> >> KDB: stack backtrace: >> >> #0 0xffffffff80947986 at kdb_backtrace+0x66 >> >> #1 0xffffffff8090d9ae at panic+0x1ce >> >> #2 0xffffffff80b81314 at vm_map_stack+0x274 >> >> #3 0xffffffff80b83584 at vm_mmap+0x674 >> >> #4 0xffffffff80b83d2f at sys_mmap+0x1cf >> >> #5 0xffffffff80cf187a at amd64_syscall+0x5ea >> >> #6 0xffffffff80cdbff7 at Xfast_syscall+0xf7 >> >> >> >> It looks like the box was compiling java related ports (java/jaxen and >> >> devel/antlr) when it panic'ed. >> > >> > This is troubling. I'm wondering what's changed and why we haven't >> > seen this before. > Well, if MAP_STACK was started used only with update, or the condition > for coalescing only holds due to changes in the update, this is not > much strange. openjdk7 doesn't appear to use MAP_STACK itself. The mmap(.. MAP_STACK..) caller looks like it is libthr. The only odd thing that stood with a quick browse of the code was that openjdk tinkers with mprotect() for "stack guard pages". These will presumably be right on the boundaries of the stacks. -- Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com; KI6FJVReceived on Thu Dec 26 2013 - 19:43:41 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:45 UTC