[
https://issues.apache.org/jira/browse/TS-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505615#comment-14505615
]
ASF GitHub Bot commented on TS-3536:
------------------------------------
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/187
TS-3536: Fix memory leak in post processing.
With this change, we effectively undo the last of the fix for ts-2497. I
would like people to take a look. Feifei and I have looked it over, and we
have been running this in production for a month or so without problems. But
since the deallocate_buffers was original removed to avoid a crash, I'd
appreciate other people's analyses.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver ts-3536
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/187.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #187
----
commit 0cb959e9d6fee20412afa8204b6159ebbfb1565b
Author: shinrich <[email protected]>
Date: 2015-04-20T23:01:46Z
TS-3536: Fix memory leak in post processing.
----
> Fixing Memory leak in POST processing
> -------------------------------------
>
> Key: TS-3536
> URL: https://issues.apache.org/jira/browse/TS-3536
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Susan Hinrichs
> Assignee: Feifei Cai
> Fix For: 6.0.0
>
>
> Opening a new bug to track concerns over fixes in TS-2497 causing a memory
> leak in certain edge cases of POST processing. The original fix in TS-2497
> removed a tunnel.deallocate_buffers(). But since tunnel.reset() is called
> before later tunnel.deallocate_buffers() are called, the original buffer
> pointers are overwritten with 0's and never deallocated.
> [~shaunmcginnity] pointed out the leak in one case (read available <= 0), and
> the deallocate_buffer() was added in that path.
> [~ffcai] identified the other path as a source of a leak for us in
> production. He added back the deallocate_buffer() in the read avail > 0
> case, and the memory leak went away. It has been running in production for
> that property for over a month without stability issues.
> I'm opening this as a new bug rather than resurrecting the other bug. Many
> other things have changed since January 2014 when TS-2497 was originally
> identified. Neither [~briang] nor [~jacksontj] could provide a reproduction
> case. I'll set up the fix as a pull request to give folks time to review
> before committing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
