From owner-freebsd-current@FreeBSD.ORG Thu Dec 26 12:05:17 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AE7CE10; Thu, 26 Dec 2013 12:05:17 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C85021A3B; Thu, 26 Dec 2013 12:05:15 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23459; Thu, 26 Dec 2013 14:05:13 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Vw9gf-00054J-Fw; Thu, 26 Dec 2013 14:05:13 +0200 Message-ID: <52BC1B41.2060900@FreeBSD.org> Date: Thu, 26 Dec 2013 14:04:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: FreeBSD Current , freebsd-java@FreeBSD.org Subject: latest openjdk7 triggers kernel panic X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Alan Cox , Marcel Moolenaar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 12:05:17 -0000 I am running FreeBSD based on the head from a few weeks ago, amd64. It seems that after a recent upgrade of openjdk7 I consistently get a kernel panic when a java process starts: panic: Bad entry start/end for new stack entry KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff803adc9b = db_trace_self_wrapper+0x2b/frame 0xfffffe02ba6fe6e0 kdb_backtrace() at 0xffffffff805cbd79 = kdb_backtrace+0x39/frame 0xfffffe02ba6fe790 panic() at 0xffffffff80597733 = panic+0x1a3/frame 0xfffffe02ba6fe810 vm_map_stack() at 0xffffffff80719f2e = vm_map_stack+0x3ce/frame 0xfffffe02ba6fe8a0 vm_mmap() at 0xffffffff8071c270 = vm_mmap+0x520/frame 0xfffffe02ba6fea30 sys_mmap() at 0xffffffff8071bad3 = sys_mmap+0x303/frame 0xfffffe02ba6feaf0 amd64_syscall() at 0xffffffff8074d0c8 = amd64_syscall+0x238/frame 0xfffffe02ba6febf0 Xfast_syscall() at 0xffffffff80733e2b = Xfast_syscall+0xfb/frame 0xfffffe02ba6febf0 Specifically, new_entry->end != top condition is true. new_entry->end is consistently greater than top by 3 pages. I suspect that java now does some hacky things with its stack and I suspect that vm_map_simplify_entry() call at the end of vm_map_insert() could be to blame. Although, the call is guarded by a check: 1290 /* 1291 * It may be possible to merge the new entry with the next and/or 1292 * previous entries. However, due to MAP_STACK_* being a hack, a 1293 * panic can result from merging such entries. 1294 */ 1295 if ((cow & (MAP_STACK_GROWS_DOWN | MAP_STACK_GROWS_UP)) == 0) 1296 vm_map_simplify_entry(map, new_entry); But that check seems to be defeated by the fact that vm_map_stack() clears our the relevant bits after saving them locally: 3335 /* 3336 * The stack orientation is piggybacked with the cow argument. 3337 * Extract it into orient and mask the cow argument so that we 3338 * don't pass it around further. 3339 * NOTE: We explicitly allow bi-directional stacks. 3340 */ 3341 orient = cow & (MAP_STACK_GROWS_DOWN|MAP_STACK_GROWS_UP); 3342 cow &= ~orient; -- Andriy Gapon