Re: Bug#736202: undeterministic output when running egrep repeatedly with the same input

[Steven Chamberlain <steven@pyro.eu.org>]

found 736202 2.16-1
found 736202 2.14-3
# regression since this version
fixed 736202 2.12-2
thanks

I see the same thing in a sid chroot on a wheezy system (kfreebsd-amd64
9.0).  Seems to affects grep 2.16-1 and 2.14-3, but not grep 2.12-2 from
wheezy running in the same chroot.


I found that in the failure case, the first grep actually outputs
"Binary file (standard input) matches" instead of the matched lines.

> $ for i in $(seq 100) ; do grep . < /usr/src/kfreebsd-headers-10.0-0/sys/sys/mount.h | grep . ; done | sort | uniq -c | sort -bn | head -n 1
>      14 Binary file (standard input) matches

`grep -a` therefore is unaffected by this bug.


With only one invocation of grep, the bug does not seem to occur:

> $ for i in $(seq 1000) ; do grep . < /usr/src/kfreebsd-headers-10.0-0/sys/sys/mount.h ; done | wc -l
> 837000
> $ for i in $(seq 1000) ; do grep . < /usr/src/kfreebsd-headers-10.0-0/sys/sys/mount.h ; done | wc -l
> 837000
> $ for i in $(seq 1000) ; do grep . < /usr/src/kfreebsd-headers-10.0-0/sys/sys/mount.h ; done | wc -l
> 837000

Piping grep to another grep triggers the bug easily:

> $ for i in $(seq 1000) ; do grep . < /usr/src/kfreebsd-headers-10.0-0/sys/sys/mount.h | grep . ; done | wc -l
> 667292
> $ for i in $(seq 1000) ; do grep . < /usr/src/kfreebsd-headers-10.0-0/sys/sys/mount.h | grep . ; done | wc -l
> 643048
> $ for i in $(seq 1000) ; do grep . < /usr/src/kfreebsd-headers-10.0-0/sys/sys/mount.h | grep . ; done | wc -l
> 665620

Only by changing the *first* grep invocation to use grep 2.12-2 from
wheezy, I don't see the problem any more:

> for i in $(seq 1000) ; do grep-2.12-2 . < /usr/src/kfreebsd-headers-10.0-0/sys/sys/mount.h | grep . ; done | wc -l
> 837000

Piping grep 2.16-1 into grep 2.12-2, the bug comes back:

> $ for i in $(seq 1000) ; do grep . < /usr/src/kfreebsd-headers-10.0-0/sys/sys/mount.h | grep-2.12-2 . ; done | wc -l
> 655588

$PIPESTATUS seems to be always ([0]="0" [1]="0")

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org