On 06/07/2010 02:38 PM, Chet Ramey wrote:
> I bet this is the kernel killing bash when the stack size resource limit
> is exceeded, not anything bash is doing or can catch.
To the contrary, it is possible to use the GPL libsigsegv to catch stack
overflow and exit with a clean error message instead
On 6/7/10 1:19 AM, Jan Schampera wrote:
> Chet Ramey wrote:
>
>> How about a stack traceback?
>
> I'm so sorry, I thought this was clear and easy to reproduce/verify.
>
> I'm using this to generate the script. The number of commands varies
> between shell versions (and likely other platform stuf
> Chet Ramey wrote:
>
> > How about a stack traceback?
>
> I'm so sorry, I thought this was clear and easy to reproduce/verify.
Sure, but you've already done the work. :-)
I'll take a look. Thanks for the report.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Oh, and to be complete:
uname -rms yields:
* Linux 2.6.26-2-amd64 x86_64
The C library is a:
* GNU libc 2.16.6-3
The crashed Bash is a:
* ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
Jan "TheBonsai"
Chet Ramey wrote:
How about a stack traceback?
I'm so sorry, I thought this was clear and easy to reproduce/verify.
I'm using this to generate the script. The number of commands varies
between shell versions (and likely other platform stuff), so you might
need to play around with the values
On 6/5/10 10:52 AM, Jan Schampera wrote:
> Hello list,
>
> somebody in chat just asked about the maximum input line length, I know
> (and told him) that this might be very platform dependent, but I did
> some tests.
>
> The result of these tests was a SEGV (after some 78K line length).
> Shouldn'
Jan Schampera schrieb:
The result of these tests was a SEGV (after some 78K line length).
Shouldn't this be sanely catched somehow by the parser? I didn't look
deeper, but it looks like a blindly filled buffer or something like that.
Sorry, I should make clear that the test case was a bunch o
