On Thu, Dec 26, 2013 at 12:01 PM, Konstantin Belousov
> On Thu, Dec 26, 2013 at 07:51:45PM +0100, Antoine Brodin wrote:
>> On Thu, Dec 26, 2013 at 7:33 PM, Peter Wemm <pe...@wemm.org> wrote:
>> > On Thu, Dec 26, 2013 at 7:39 AM, Antoine Brodin <anto...@freebsd.org>
>> > wrote:
>> >> On Thu, Dec 26, 2013 at 1:04 PM, Andriy Gapon <a...@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 - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"