[
https://issues.apache.org/jira/browse/TS-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2765:
----------------------------------
Description:
While debugging memory leak during SPDY testing on a production host noticed a
couple of leaks (13 bytes each) during SSL Config initialization. Below is the
valgrind output showing the leak. These bugs also existing in 4.0.
==29790== Thread 1:
==29790== 13 bytes in 1 blocks are definitely lost in loss record 168 of 2,653
==29790== at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==29790== by 0x4E50E3D: ats_malloc (ink_memory.cc:50)
==29790== by 0x4E50E9D: _xstrdup (ink_memory.cc:236)
==29790== by 0x70E90B: RecDataSet(RecDataT, RecData*, RecData*)
(RecUtils.cc:148)
==29790== by 0x70729C: RecGetRecord_Xmalloc(char const*, RecDataT, RecData*,
bool) (RecCore.cc:780)
==29790== by 0x707327: RecGetRecordString_Xmalloc(char const*, char**, bool)
(RecCore.cc:382)
==29790== by 0x6DAF2C: SSLConfigParams::initialize() (SSLConfig.cc:214)
==29790== by 0x6DB5AD: SSLConfig::startup() (SSLConfig.cc:265)
==29790== by 0x6DBB29: SSLNetProcessor::start(int, unsigned long)
(SSLNetProcessor.cc:51)
==29790== by 0x4D0723: main (Main.cc:1557)
==29790==
==29790== 13 bytes in 1 blocks are definitely lost in loss record 169 of 2,653
==29790== at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==29790== by 0x4E50E3D: ats_malloc (ink_memory.cc:50)
==29790== by 0x4E50E9D: _xstrdup (ink_memory.cc:236)
==29790== by 0x70E90B: RecDataSet(RecDataT, RecData*, RecData*)
(RecUtils.cc:148)
==29790== by 0x70729C: RecGetRecord_Xmalloc(char const*, RecDataT, RecData*,
bool) (RecCore.cc:780)
==29790== by 0x707327: RecGetRecordString_Xmalloc(char const*, char**, bool)
(RecCore.cc:382)
==29790== by 0x6DB0E2: SSLConfigParams::initialize() (SSLConfig.cc:246)
==29790== by 0x6DB5AD: SSLConfig::startup() (SSLConfig.cc:265)
==29790== by 0x6DBB29: SSLNetProcessor::start(int, unsigned long)
(SSLNetProcessor.cc:51)
==29790== by 0x4D0723: main (Main.cc:1557)
was:
While debugging memory leak during SPDY testing on a production host noticed a
couple of leaks (13 bytes each) during SSL Config initialization. Below is the
valgrind output showing the leak. These bugs also existing in 4.0. Also,
noticed that the code in master is incorrectly freeing
"serverCertChainFilename".
==29790== Thread 1:
==29790== 13 bytes in 1 blocks are definitely lost in loss record 168 of 2,653
==29790== at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==29790== by 0x4E50E3D: ats_malloc (ink_memory.cc:50)
==29790== by 0x4E50E9D: _xstrdup (ink_memory.cc:236)
==29790== by 0x70E90B: RecDataSet(RecDataT, RecData*, RecData*)
(RecUtils.cc:148)
==29790== by 0x70729C: RecGetRecord_Xmalloc(char const*, RecDataT, RecData*,
bool) (RecCore.cc:780)
==29790== by 0x707327: RecGetRecordString_Xmalloc(char const*, char**, bool)
(RecCore.cc:382)
==29790== by 0x6DAF2C: SSLConfigParams::initialize() (SSLConfig.cc:214)
==29790== by 0x6DB5AD: SSLConfig::startup() (SSLConfig.cc:265)
==29790== by 0x6DBB29: SSLNetProcessor::start(int, unsigned long)
(SSLNetProcessor.cc:51)
==29790== by 0x4D0723: main (Main.cc:1557)
==29790==
==29790== 13 bytes in 1 blocks are definitely lost in loss record 169 of 2,653
==29790== at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==29790== by 0x4E50E3D: ats_malloc (ink_memory.cc:50)
==29790== by 0x4E50E9D: _xstrdup (ink_memory.cc:236)
==29790== by 0x70E90B: RecDataSet(RecDataT, RecData*, RecData*)
(RecUtils.cc:148)
==29790== by 0x70729C: RecGetRecord_Xmalloc(char const*, RecDataT, RecData*,
bool) (RecCore.cc:780)
==29790== by 0x707327: RecGetRecordString_Xmalloc(char const*, char**, bool)
(RecCore.cc:382)
==29790== by 0x6DB0E2: SSLConfigParams::initialize() (SSLConfig.cc:246)
==29790== by 0x6DB5AD: SSLConfig::startup() (SSLConfig.cc:265)
==29790== by 0x6DBB29: SSLNetProcessor::start(int, unsigned long)
(SSLNetProcessor.cc:51)
==29790== by 0x4D0723: main (Main.cc:1557)
> Memory Leak in SSLConfig initialization
> ---------------------------------------
>
> Key: TS-2765
> URL: https://issues.apache.org/jira/browse/TS-2765
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Sudheer Vinukonda
> Labels: SPDY_ATS, yahoo
>
> While debugging memory leak during SPDY testing on a production host noticed
> a couple of leaks (13 bytes each) during SSL Config initialization. Below is
> the valgrind output showing the leak. These bugs also existing in 4.0.
> ==29790== Thread 1:
> ==29790== 13 bytes in 1 blocks are definitely lost in loss record 168 of 2,653
> ==29790== at 0x4C279EE: malloc (vg_replace_malloc.c:270)
> ==29790== by 0x4E50E3D: ats_malloc (ink_memory.cc:50)
> ==29790== by 0x4E50E9D: _xstrdup (ink_memory.cc:236)
> ==29790== by 0x70E90B: RecDataSet(RecDataT, RecData*, RecData*)
> (RecUtils.cc:148)
> ==29790== by 0x70729C: RecGetRecord_Xmalloc(char const*, RecDataT,
> RecData*, bool) (RecCore.cc:780)
> ==29790== by 0x707327: RecGetRecordString_Xmalloc(char const*, char**,
> bool) (RecCore.cc:382)
> ==29790== by 0x6DAF2C: SSLConfigParams::initialize() (SSLConfig.cc:214)
> ==29790== by 0x6DB5AD: SSLConfig::startup() (SSLConfig.cc:265)
> ==29790== by 0x6DBB29: SSLNetProcessor::start(int, unsigned long)
> (SSLNetProcessor.cc:51)
> ==29790== by 0x4D0723: main (Main.cc:1557)
> ==29790==
> ==29790== 13 bytes in 1 blocks are definitely lost in loss record 169 of 2,653
> ==29790== at 0x4C279EE: malloc (vg_replace_malloc.c:270)
> ==29790== by 0x4E50E3D: ats_malloc (ink_memory.cc:50)
> ==29790== by 0x4E50E9D: _xstrdup (ink_memory.cc:236)
> ==29790== by 0x70E90B: RecDataSet(RecDataT, RecData*, RecData*)
> (RecUtils.cc:148)
> ==29790== by 0x70729C: RecGetRecord_Xmalloc(char const*, RecDataT,
> RecData*, bool) (RecCore.cc:780)
> ==29790== by 0x707327: RecGetRecordString_Xmalloc(char const*, char**,
> bool) (RecCore.cc:382)
> ==29790== by 0x6DB0E2: SSLConfigParams::initialize() (SSLConfig.cc:246)
> ==29790== by 0x6DB5AD: SSLConfig::startup() (SSLConfig.cc:265)
> ==29790== by 0x6DBB29: SSLNetProcessor::start(int, unsigned long)
> (SSLNetProcessor.cc:51)
> ==29790== by 0x4D0723: main (Main.cc:1557)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
