Your message dated Tue, 20 Sep 2016 15:54:15 +0200
with message-id <20160920135415.2cxltmbqudlmu...@riseup.net>
and subject line Re: grep: please make finding strings from large hard disk 
images use O(1) memory
has caused the Debian Bug report #458098,
regarding grep: please make finding strings from large hard disk images use 
O(1) memory
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
458098: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458098
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: grep
Version: 2.5.3~dfsg-3
Severity: wishlist

Hi,

I recently tried to find a string from a large hard disk image and was
surprised when grep returned "Cannot allocate memory". Apparently the
image contained so large areas of zeroes that grep ran out of memory
when I it tried to hold those areas in memory (it was probably looking
for "\n"?). My wish is that grep would use constant amount of memory
vrt. the size of input (hard disk image).

You can reproduce this problem with

$ dd if=/dev/zero bs=1M count=1k | grep x
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.49402 seconds, 239 MB/s
grep: (standard input): Cannot allocate memory

Note that busybox's grep handles this case just fine:

$ dd if=/dev/zero bs=1M count=1k | busybox grep x
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 349.732 seconds, 3.1 MB/s

I did these tests on an 32-bit x86 system with 4 GB of RAM. I am not
sure if this bug should be seen as a duplicate of #195719 or #358858.

best regards,
Timo Lindfors



--- End Message ---
--- Begin Message ---
Version: 2.25-6

Hi,

El 28/12/07 a las 18:48, Timo Juhani Lindfors escribiĆ³:
> Package: grep
> Version: 2.5.3~dfsg-3
> Severity: wishlist
> 
> Hi,
> 
> I recently tried to find a string from a large hard disk image and was
> surprised when grep returned "Cannot allocate memory". Apparently the
> image contained so large areas of zeroes that grep ran out of memory
> when I it tried to hold those areas in memory (it was probably looking
> for "\n"?). My wish is that grep would use constant amount of memory
> vrt. the size of input (hard disk image).
> 
> You can reproduce this problem with
> 
> $ dd if=/dev/zero bs=1M count=1k | grep x
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB) copied, 4.49402 seconds, 239 MB/s
> grep: (standard input): Cannot allocate memory
> 
> Note that busybox's grep handles this case just fine:
> 
> $ dd if=/dev/zero bs=1M count=1k | busybox grep x
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB) copied, 349.732 seconds, 3.1 MB/s
> 
> I did these tests on an 32-bit x86 system with 4 GB of RAM. I am not
> sure if this bug should be seen as a duplicate of #195719 or #358858.
> 

I am closing this old bug since I am unable to reproduce it on the
current grep version in unstable, 2.25-6.

1024+0 registros leĆ­dos
1024+0 registros escritos
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 1,3841 s, 776 MB/s

Don't hesitate to reopen it if you think the issue is still present.

Cheers,

Santiago

--- End Message ---

Reply via email to