[
https://issues.apache.org/jira/browse/TS-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730542#comment-13730542
]
Yunkai Zhang commented on TS-2063:
----------------------------------
I think the inner do-while is an optimization to reduce the calling of write()
function.
But it breaks the original code, it's the root cause of the memcpy() overflow
issue which just has been fixed by Quehan.
> LogFile::write_ascii_logbuffer3() can silently drop log entries
> ---------------------------------------------------------------
>
> Key: TS-2063
> URL: https://issues.apache.org/jira/browse/TS-2063
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Labels: A
> Fix For: 3.5.0
>
>
> Couple of things here.
> 1. Why do we need both LogFile::write_ascii_logbuffer() and
> LogFile::write_ascii_logbuffer3()? The former is only used by traffic_logcat,
> we ought to be able to refactor and unify this.
> 2. In LogFile::write_ascii_logbuffer3(), it's possible that writing to the
> LogBuffer has produced more entries than we can marshal and fit into an ascii
> buffer. When that happens, we'd simply drop those log entries on the floor.
> 3. It's possible this also relates to TS-777.
> As for 2, I think we should at a minimum break out of the inner loop in the
> else branch of testing if an entry fits (instead of silently dropping the
> entry). This puts weirdness in the outer loop, for the case where a single
> entry can't fit in the ascii buffer (I don't know if it can happen, but it
> might).
> A suggestion from amc is to refactor both loops into a single loop that
> iterates and checks size restrictions. This is actually similar to how
> LogFile::write_ascii_logbuffer() works as well (so fixing / unifying issue 1)
> above might be the way to resolve this as well).
> As for 3) I have no other proof that this bug is affiliated with TS-777,
> other than they both have issues in the same area. And thinking about if, if
> you increase proxy.config.log.log_buffer_size but leave
> proxy.config.log.max_line_size the same, we get much larger LogBuffers, but
> the ascii buffer is still the same size (so we're almost certain to trigger
> 2) above).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira