[
https://issues.apache.org/jira/browse/TS-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1241:
------------------------------
Fix Version/s: 3.1.4
> massive memory leak seen when using ATS-3.0.2
> ---------------------------------------------
>
> Key: TS-1241
> URL: https://issues.apache.org/jira/browse/TS-1241
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.0.2
> Environment: linux RHEL6.2
> Reporter: Aidan McGurn
> Priority: Critical
> Fix For: 3.1.4
>
> Attachments: INK-118.patch
>
>
> when throttling through proxy traffic 1000TPS within a few minutes we are
> seeing a memorry growth of some MB, continuing upwards until end of test.
> When looking at the INK allocs and INK free's,
> Our custom plugin transactions use a scheduleNext routine which schedules the
> next part of the transaction using 'TSHttpSchedule(m_contp, m_txn, 0);'..
> this would seem the correct API as its a HTTP proxy we are running.
> TSContCreates (INKContAllocator.alloc()) and TSContDestroys match up however
> INKContInternal::destroy does not simply delete the memory but checks a
> m_deletable var before doing so - this var is controlled by m_event_count -
> but in our case the count does not appear to be handled correctly - i.e. this
> counter is decremented and incremented depending on conditions.
> It does not appear to be getting incremented in our case => memory never gets
> deleted as m_deletable var doesn't get set => we see a massive memory leak -
> Looking at the code, the TSContSchedule functions correctly increment the
> event counter but TSHttpSchedule does not appear to -
> i added in an incrementor:
> INKApi.cc/TSHttpSchedule:
> INKContInternal *i = (INKContInternal *) contp;
> if (ink_atomic_increment((int *) &i->m_event_count, 1) < 0)
> ink_assert (!"not reached");
> in TSHttpSchedule and reload tested - counter is correctly handled and memory
> leak is fixed -
> IS this a bug in ATS or have i missed the correct way to run our http plugin
> using TSHttpSchedule (i can't see how we are mean't to use TSContSchedule as
> its TSHttpSchedule which requires the txn parameter so i think this is the
> correct API we are using)
> using 3.0.2 and can supply above as a patch if required
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
