Re: unbounded recursive call in a shell script crashes zsh

[Jérémie Roquet <jroquet@xxxxxxxxxxxxx>]

2017-04-13 16:30 GMT+02:00 Kamil Dudka <kdudka@xxxxxxxxxx>:
> I was trying to reduce the stack usage of zsh but was not really successful,
> mainly because I do not know how to efficiently find the automatic variables
> that consumed the biggest portion of the stack. […]  Do you have any
> estimation about where else the stack allocation could be reduced?

We get some useful information if we link without the “-s” flag (and
it can help to compile with “-O0 -ggdb” as well).

Then, using gdb's “backtrace” we get that the stack is being consumed
by recursion throught the following 13 frames:

#18596 0x0000000000464733 in execif (state=0x7fffffffc9f0, do_exec=0)
at loop.c:572
#18597 0x00000000004360e8 in execcmd_exec (state=0x7fffffffc9f0,
eparams=0x7fffffffc5e0, input=0, output=0, how=18, last1=2) at
exec.c:3705
#18598 0x00000000004307ea in execpline2 (state=0x7fffffffc9f0,
pcode=67, how=18, input=0, output=0, last1=0) at exec.c:1872
#18599 0x000000000042f505 in execpline (state=0x7fffffffc9f0,
slcode=13314, how=18, last1=0) at exec.c:1602
#18600 0x000000000042e859 in execlist (state=0x7fffffffc9f0,
dont_change_job=1, exiting=0) at exec.c:1360
#18601 0x000000000042df2f in execode (p=0x7019e0, dont_change_job=1,
exiting=0, context=0x4ba7a8 "shfunc") at exec.c:1141
#18602 0x000000000043ae92 in runshfunc (prog=0x7019e0, wrap=0x0,
name=0x7ffff7fe7028 "foo") at exec.c:5675
#18603 0x000000000043a763 in doshfunc (shfunc=0x701a70,
doshargs=0x7ffff7ff2568, noreturnval=0) at exec.c:5539
#18604 0x000000000043979f in execshfunc (shf=0x701a70,
args=0x7ffff7ff2568) at exec.c:5113
#18605 0x00000000004362c3 in execcmd_exec (state=0x7fffffffd830,
eparams=0x7fffffffd420, input=0, output=0, how=18, last1=1) at
exec.c:3757
#18606 0x00000000004307ea in execpline2 (state=0x7fffffffd830,
pcode=131, how=18, input=0, output=0, last1=1) at exec.c:1872
#18607 0x000000000042f505 in execpline (state=0x7fffffffd830,
slcode=3074, how=18, last1=1) at exec.c:1602
#18608 0x000000000042e859 in execlist (state=0x7fffffffd830,
dont_change_job=0, exiting=1) at exec.c:1360

And using gdb's “info frame” on each frame and looking at “frame at”
and “called by frame at”, we get:

execlist: 416 bytes
execpline: 464 bytes
execpline2: 208 bytes
execcmd_exec: 1056 bytes
execshfunc: 336 bytes
doshfunc: 736 bytes
runshfunc: 336 bytes
execode: 96 bytes
execlist: 416 bytes
execpline: 464 bytes
execpline2: 208 bytes
execcmd_exec: 1056 bytes
execif: 64 bytes

If we aggregate, it gives us:

execcmd_exec: 2112 bytes
execpline: 928 bytes
execlist: 832 bytes
doshfunc: 736 bytes
execpline2: 416 bytes
execshfunc: 336 bytes
runshfunc: 336 bytes
execode: 96 bytes
execif: 64 bytes

Hence a total of 5856 bytes per recursion, or 5719 kiB for 10000 recursions.

Best regards,

-- 
Jérémie