Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.1.0
Description
As best I can track this down, the problem arises during log creation. For reasons I would prefer to not know, log buffers are written to binary files using the LogFile.cc:writeln which helpfully appends a newline to the binary data. Unless the binary data already ends with a newline, in which case it doesn't. logstats, when reading the file, always add an extra byte to read to skip over this newline, which can be problematic in the latter case. Whether this happens seems to depend on the client brower because the last field in the standard log format is XID, a MIME field. LogAccessHttp::marshal_client_accelerator_id pulls the XID out of the MIME fields and then adds one to the returned length, to account for the possibly non-existent terminating nul (it being a MIME field). That extra byte gets carried along and written out as part of the XID. If it turns out to be a newline, then there is a problem.
There's so much wrongness here I don't even know where to start. There's even expensive code in both logcat to detect small shifts (such as being off by one due to a missing newline) and re-synchronize. logstats has similar code but it only used when starting at an offset in to the log file.
Attachments
Attachments
Issue Links
- blocks
-
TS-1022 LogEntryHeader is a serialized structure but uses vague types.
- Closed