it seems stable, proved by the stress tests. :)

30k smaller code.

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>

Also some preparatory cleanups for future dumpoops patch are included

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>

CKerneloopsScanner::Run - scan syslog file first, then dmesg
(was other way around)

CKerneloopsScanner::SaveOopsToDebug - cast time_t and size_t to long
when we feed them to snprintf

CKerneloopsScanner::ScanSysLogFile - do not seek to negative offsets,
 POSIX does not allow that

CSysLog::QueueOops - plug memory leak

Also used some abrtlib functions where appropriate, use open instead of fopen
where appropriate, do not check error in time() - it never fails,
move around bits of code in CKerneloopsScanner
to make it easier in future to create a tool for parsing
arbitrary files for oopses.

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>

It is not too rare that '\0' chars appear in /var/log/messages. I saw a
real-life case where kerneloops would show a popup with the same old oops
after every login. It turned out that there were NUL chars in the log which
prevented kerneloops from seeing its marker, so it always treated the old oops
in the log as new.
This patch fixes it by always going through the whole known length of the
buffer (not stopping on NUL chars) and using less string-oriented functions in
fill_lineinfo().

* backport of 14e769d7093179943015ff88d0d3bdd65b2947f7
* Author: Michal Schmidt <mschmidt@redhat.com>

The linepointer array is huge!:
    linepointer = calloc(buflen+1, sizeof(char*));
buflen can be as much as 32 MB, that makes it allocate 32M*8 = 256M on x86_64.

Fix it by growing the allocation dynamically as we find interesting lines in
the log.