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 -- G. Paul Ziemba FreeBSD unix: 5:46PM up 6:38, 8 users, load averages: 3.31, 3.79, 2.25
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 handlerThe 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.