in reply to Perl Out of memory error
Since there are only three references to $buf_size, and indeed the read() function does read $file_size, I wonder if this script might contain a basic logic error. If, as the regex (that appears to be the only use of the file content ...) implies, the purpose of the script is to locate a certain sentinel string that begins with "999", it does not appear to me that it should be necessary to read the entire contents of the file in order to do that.
I’d suggest looking at one of those input files with a hex-editor to see if you can puzzle out how the file is built. The EBCDIC code (see, e.g. http://www.simotime.com/asc2ebc1.htm) is based more-or-less on punched cards, and so the characters and digits are in four discontiguous groups: $C1-C9, $D1-D9, $E1-E9, $F0-F9, the last group being the digits 0-9. So, the “eyecatcher” you are looking for should be very obvious in hex.
My feeling is that the program “is wrong,” even if “it works” right now ... the giveaway being that it fails for very large files when, intuitively, there is not much no reason why it should.
The entire business of seek()ing to a position near to end-of-file, and then reading a chunk, simply makes no sense with $file_size, but it makes much more sense with $bufsize. It is more-than-a-guess on my part that this was the designer’s intention ... especially if the COBOL records turn out to be (as I suspect they are ...) 6,000 bytes long, or some equal-sized division thereof. They wanted to read “the last records,” and knew that the files could be arbitrarily large.
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Perl Out of memory error
by Anonymous Monk on Oct 05, 2015 at 21:48 UTC | |
by Anonymous Monk on Oct 05, 2015 at 22:15 UTC | |
by Anonymous Monk on Oct 05, 2015 at 22:16 UTC | |
by locked_user sundialsvc4 (Abbot) on Oct 06, 2015 at 02:01 UTC | |
by Anonymous Monk on Oct 06, 2015 at 17:56 UTC |