From owner-freebsd-stable@freebsd.org Sun Jul 23 05:51:50 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87065C7D1CB for ; Sun, 23 Jul 2017 05:51:50 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 50F9774DF2 for ; Sun, 23 Jul 2017 05:51:50 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v6N5pgdZ082546; Sat, 22 Jul 2017 22:51:46 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201707230551.v6N5pgdZ082546@gw.catspoiler.org> Date: Sat, 22 Jul 2017 22:51:42 -0700 (PDT) From: Don Lewis Subject: Re: stable/11 r321349 crashing immediately To: pz-freebsd-stable@ziemba.us cc: freebsd-stable@FreeBSD.org In-Reply-To: <201707230543.v6N5gwwH082362@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 05:51:50 -0000 On 22 Jul, To: pz-freebsd-stable@ziemba.us wrote: > On 22 Jul, G. Paul Ziemba wrote: >> My previous table had an error in the cumulative size column >> (keyboard made "220" into "20" when I was plugging into the hex >> calculator), so thet stack is 0x200 bigger than I originally thought: >> >> Frame Stack Pointer sz cumu function >> ----- ------------- --- ---- ---------------- >> 44 0xfffffe085cfa8a10 amd64_syscall >> 43 0xfffffe085cfa88b0 160 160 syscallenter >> 42 0xfffffe085cfa87f0 220 380 sys_execve >> 41 0xfffffe085cfa87c0 30 3B0 kern_execve >> 40 0xfffffe085cfa8090 730 AE0 do_execve >> 39 0xfffffe085cfa7ec0 1D0 CB0 namei >> 38 0xfffffe085cfa7d40 180 E30 lookup >> 37 0xfffffe085cfa7cf0 50 E80 VOP_LOOKUP >> 36 0xfffffe085cfa7c80 70 EF0 VOP_LOOKUP_APV >> 35 0xfffffe085cfa7650 630 1520 nfs_lookup >> 34 0xfffffe085cfa75f0 60 1580 VOP_ACCESS >> 33 0xfffffe085cfa7580 70 15F0 VOP_ACCESS_APV >> 32 0xfffffe085cfa7410 170 1760 nfs_access >> 31 0xfffffe085cfa7240 1D0 1930 nfs34_access_otw >> 30 0xfffffe085cfa7060 1E0 1B10 nfsrpc_accessrpc >> 29 0xfffffe085cfa6fb0 B0 1BC0 nfscl_request >> 28 0xfffffe085cfa6b20 490 2050 newnfs_request >> 27 0xfffffe085cfa6980 1A0 21F0 clnt_reconnect_call >> 26 0xfffffe085cfa6520 460 2650 clnt_vc_call >> 25 0xfffffe085cfa64c0 60 26B0 sosend >> 24 0xfffffe085cfa6280 240 28F0 sosend_generic >> 23 0xfffffe085cfa6110 170 2A60 tcp_usr_send >> 22 0xfffffe085cfa5ca0 470 2ED0 tcp_output >> 21 0xfffffe085cfa5900 3A0 3270 ip_output >> 20 0xfffffe085cfa5880 80 32F0 looutput >> 19 0xfffffe085cfa5800 80 3370 if_simloop >> 18 0xfffffe085cfa57d0 30 33A0 netisr_queue >> 17 0xfffffe085cfa5780 50 33F0 netisr_queue_src >> 16 0xfffffe085cfa56f0 90 3480 netisr_queue_internal >> 15 0xfffffe085cfa56a0 50 34D0 swi_sched >> 14 0xfffffe085cfa5620 80 3550 intr_event_schedule_thread >> 13 0xfffffe085cfa55b0 70 35C0 sched_add >> 12 0xfffffe085cfa5490 120 36E0 sched_pickcpu >> 11 0xfffffe085cfa5420 70 3750 sched_lowest >> 10 0xfffffe085cfa52a0 180 38D0 cpu_search_lowest >> 9 0xfffffe085cfa52a0 0 38D0 cpu_search >> 8 0xfffffe085cfa5120 180 3A50 cpu_search_lowest >> 7 0xfffffe085cfa5120 0 3A50 cpu_search >> 6 0xfffffe085cfa4fa0 180 3BD0 cpu_search_lowest >> 5 0xfffffe0839778f40 signal handler > > The stack is aligned to a 4096 (0x1000) boundary. The first access to a > local variable below 0xfffffe085cfa5000 is what triggered the trap. The > other end of the stack must be at 0xfffffe085cfa9000 less a bit. I don't > know why the first stack pointer value in the trace is > 0xfffffe085cfa8a10. That would seem to indicate that amd64_syscall is > using ~1500 bytes of stack space. Actually there could be quite a bit of CPU context that gets saved. That could be sizeable on amd64.