Segfaulting script

Segfaulting script

[Andrew Ruder]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

Hey all,

I was writing a script today and was getting a segfault (on what turned
out to be a very incorrect line), but nonetheless...  The attached script
when sourced into a running shell causes future tab completion to die.  I
have verified this against 4.2.6 and 4.3.2.  Looking at a backtrace
seems to show that it is hitting infinite recursion.

 % zsh -f
 [\u@\h \W]\$ . ./test.zsh
 Ok, try tab completion...
 [\u@\h \W]\$ <TAB>zsh: segmentation fault (core dumped)  zsh -f

Thanks,
Andrew Ruder

P.S. You don't have to tell me how wrong/stupid/etc.. the script in
question is... :)

-- 
Andrew Ruder <andy@aeruder.net>
http://www.aeruder.net

[-- Attachment #2: test.zsh --]
[-- Type: text/plain, Size: 152 bytes --]

#!/bin/zsh

autoload -U compinit
compinit

function testfunc { 
	local flag_strings=()
	local anything 
}

testfunc

echo "Ok, try tab completion..."

Re: Segfaulting script

[Frank Terbeck]

Andrew Ruder <andy@aeruder.net>:
> I was writing a script today and was getting a segfault (on what turned
> out to be a very incorrect line), but nonetheless...  The attached script
> when sourced into a running shell causes future tab completion to die.  I
> have verified this against 4.2.6 and 4.3.2.  Looking at a backtrace
> seems to show that it is hitting infinite recursion.

I think, that's the segfault you talked about on IRC.
I don't know if this is the same bug, but it might be closely related:

[snip]
% zsh -f
% testfunc() { local foo=() ; local bar }
% testfunc
% autoload compinit
% compinit
[1]    12388 segmentation fault (core dumped)  zsh -f
[snap]

Regards, Frank

Re: Segfaulting script

[Bart Schaefer]

On Jun 16,  1:03pm, Frank Terbeck wrote:
}
} I don't know if this is the same bug, but it might be closely related:
} 
} [snip]
} % zsh -f
} % testfunc() { local foo=() ; local bar }

You can't assign values to an array in a "local" statement.  When zsh
parses the above, it's seeing

	local
	foo=
	()	<-- empty parens means we're defining a function!
	;
	local
	bar

The result is that you define both "local" and "foo=" as the names of
functions, each of which has the function body

	local bar

which (of course) is a recursive call to the newly-created function
"local".  I don't get a segfault with 4.3.2-dev-1, I get an error:

zsh% local
local:10: maximum nested function level reached
zsh% 

The fact that "compinit" or a completion comes next is a red herring; any
function that used "local" would cause the error.

My guess would be that you get a segfault when the compile-time setting
of the maximum function depth is large enough that you run out of memory
before the limit is hit.  There's not a whole lot we can do about that.

Re: Segfaulting script

[Frank Terbeck]

Bart Schaefer <schaefer@brasslantern.com>:
> On Jun 16,  1:03pm, Frank Terbeck wrote:
> }
> } I don't know if this is the same bug, but it might be closely related:
> } 
> } [snip]
> } % zsh -f
> } % testfunc() { local foo=() ; local bar }
> 
> You can't assign values to an array in a "local" statement.  When zsh
> parses the above, it's seeing
[...]

Yes, I know that the assignment does not make sense.

> which (of course) is a recursive call to the newly-created function
> "local".  I don't get a segfault with 4.3.2-dev-1, I get an error:
> 
> zsh% local
> local:10: maximum nested function level reached
> zsh% 

Okay.

> The fact that "compinit" or a completion comes next is a red herring; any
> function that used "local" would cause the error.

Thanks for clarifying that.

> My guess would be that you get a segfault when the compile-time setting
> of the maximum function depth is large enough that you run out of memory
> before the limit is hit.  There's not a whole lot we can do about that.

Hm, definitely no nice, but I trust your judgement.

Regards, Frank

Re: Segfaulting script

[Bart Schaefer]

On Jun 17,  8:14pm, Frank Terbeck wrote:
}
} > You can't assign values to an array in a "local" statement.
} 
} Yes, I know that the assignment does not make sense.

Certainly.  I was just pointing out for the peanut gallery exactly what
went wrong.
 
} > My guess would be that you get a segfault when the compile-time
} > setting of the maximum function depth is large enough that you run
} > out of memory before the limit is hit. There's not a whole lot we
} > can do about that.
} 
} Hm, definitely no nice, but I trust your judgement.

It might be possible to estimate a run-time value for the recursion
depth based on ulimit sizes, but some OSs are willing to overpromise on
memory allocations in the hope that all that was asked for will never
really be used.  In such a case there's no way to avoid the segfault if
more is used than truly is available.