Aidan McGurn created TS-1241:
--------------------------------
Summary: 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
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
