grep-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Grep-devel] [platform-testers] new snapshot available: grep-3.1.48-


From: Jim Meyering
Subject: Re: [Grep-devel] [platform-testers] new snapshot available: grep-3.1.48-7eea
Date: Sun, 16 Dec 2018 11:24:07 -0800

On Sun, Dec 16, 2018 at 11:21 AM Jim Meyering <address@hidden> wrote:
>
> On Sat, Dec 15, 2018 at 10:55 PM Bruno Haible <address@hidden> wrote:
> >
> > On HardenedBSD 11/x86_64 (with libsigsegv installed), the stack-overflow 
> > test
> > fails.
> >
> > Since HardenedBSD 11 is a derivate of FreeBSD 11, I tried this as well:
> > On FreeBSD 11/x86_64 (with libsigsegv installed), the stack-overflow test
> > succeeds.
> >
> > What's the difference?
> >
> > On FreeBSD 11 (with libsigsegv):
> > 1 million opening parentheses -> "grep: in:1: Unmatched ( or \("
> > 2 million opening parentheses -> "grep: stack overflow"
> >
> > On HardenedBSD 11 (with libsigsegv):
> > grep never printed "stack overflow"
> > 1 million opening parentheses -> "grep: in:1: Unmatched ( or \("
> > 2 million opening parentheses -> "grep: in:1: Unmatched ( or \("
> > 4 million opening parentheses -> "grep: stack overflow"
> > 10 million opening parentheses -> "grep: stack overflow"
> >
> > So, HardenedBSD just needs a larger input to make the stack overflow.
> >
> > 'ulimit -a' shows the difference: The stack size limit (in kiB) is
> > - on FreeBSD 11:      524288  (so, 1/2 GiB)
> > - on HardenedBSD 11: 1048576  (so, 1 GiB).
> >
> > The attached patch fixes the problem for me. But you may consider
> > to derive the maximum try from the `ulimit -s` value.
>
> Nice. Thank you for investigating and fixing.
> I'll be happy to use your patch, but am adding one more term: 1000, to
> test up to 10 million parentheses. That should give us a little more
> time before systems with even larger stack limits cause a false
> failure here.
>
> I don't want to attempt to guess a limit from ulimit-reported numbers,
> because it would have to be a heuristic and hence would provide one
> more opportunity for test malfunction.

PS. here's the patch I'm pushing:

Attachment: bruno-hardenedbsd.diff
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]