Change Details

rS313948 partially fixed --mmap behavior but took an odd and incomplete approach. This commit partially reverts it and does it the more correct way- by just consuming the rest of the buffer and moving on. The previous approach was wrong because that's just now how --mmap operates. The part of the loop now behind a `filebehave != FILE_MMAP` is only to see if we hit an EOL/EOF in part of the file we had not yet read in. There's no point in doing this when for --mmap because we already have the entire buffer mapped, so if we hit this loop then we're really looking at EOF. The previous fix was resulting in getting hit by a (SIG)BUS in certain scenarios, such as reported in PR 219402, because we were copying past the end of the `lnbuf` for reasons that don't make sense. PR: 219402

rS313948 partially fixed --mmap behavior but took an odd and incomplete approach. This commit generally reverts it and does it the more correct way- by just consuming the rest of the buffer and moving on. The previous approach was wrong because that's just now how --mmap operates. The part of the loop now behind a `filebehave != FILE_MMAP` is only to see if we hit an EOL/EOF in part of the file we had not yet read in. There's no point in doing this when for --mmap because we already have the entire buffer mapped, so if we hit this loop then we're really looking at EOF. The previous fix was resulting in getting hit by a (SIG)BUS in certain scenarios, such as reported in PR 219402, because we were copying past the end of the `lnbuf` for reasons that don't make sense. PR: 219402

rS313948 partially fixed --mmap behavior but took an odd and incomplete approach. This commit partigenerally reverts it and does it the more correct way- by just consuming the rest of the buffer and moving on. The previous approach was wrong because that's just now how --mmap operates. The part of the loop now behind a `filebehave != FILE_MMAP` is only to see if we hit an EOL/EOF in part of the file we had not yet read in. There's no point in doing this when for --mmap because we already have the entire buffer mapped, so if we hit this loop then we're really looking at EOF. The previous fix was resulting in getting hit by a (SIG)BUS in certain scenarios, such as reported in PR 219402, because we were copying past the end of the `lnbuf` for reasons that don't make sense. PR: 219402