Bug#70762: textutils: tail segfault

["H. S. Teoh" <hsteoh@quickfur.yi.org>]

Hi, I've tested this bug myself, and here's what I found.  Doing an strace
after a ulimit -v, I get: 

[snipped lots of brk()'s]
brk(0x889d000)                          = 0x889d000
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192)
= 8192
brk(0x889f000)                          = 0x889d000
old_mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = -1 ENOMEM (Cannot allocate memory)
old_mmap(NULL, 2097152, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot
allocate memory)
old_mmap(NULL, 1048576, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot
allocate memory)
old_mmap(NULL, 2097152, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot
allocate memory)
old_mmap(NULL, 1048576, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot
allocate memory)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++


It looks like somewhere in libc, it's not catching/handling ENOMEM
properly.

But the original bug seems to be more of an issue: shouldn't it be a bug
that tail chews up infinite amounts of memory when it can't find an
end-of-line char? IMHO, tail should just bail out when it finds a line
which is more than, say 10MB long (I'm being generous about limits here). 
I mean, when there is no newline for 10MB's worth of data, is there even
any usefulness to tail anymore? I just can't imagine any scenario where
it'd actually do anything *useful*.

I think there is no reason to let tail grow without bounds and chew up the
entire machine's memory. Tail should be patched to bail out after reaching
a (very high) limit. (Or perhaps, just in case, we can add an option to
tail to allow it to go past the limit... but I seriously doubt it's worth
the effort.)

W.r.t. to tailing /dev/zero, bug #162257 should already take care of it.
Nevertheless, I still think tail should impose a finite limit on line
length. Just because chewing up the entire machine's memory without
producing any meaningful output just seems unacceptable to me.


T

-- 
Roasting my brains over a slow fire. Please do not interrupt this process.