Bug #1367
closedthe memory allocated by libhtp was not freed.
Description
In the 250,000 CPS test(IxLoad XT80), I found the problem which was seen as memory leak.
bstr_alloc() and hp_list_array_create() function in libhtp allocate large memory and does not free it.
Files
Updated by Victor Julien about 9 years ago
This is a regular call graph, correct? Any way to get a specific report about the leaks you're seeing?
Updated by jeongun baek about 9 years ago
Victor Julien wrote:
This is a regular call graph, correct? Any way to get a specific report about the leaks you're seeing?
before running CPS test, memory usage is just 30G.
But after the test, memory usage is rising to 100G and the memory not freed after 24 hours.
Is it not memory leak ?
Updated by Victor Julien about 9 years ago
Sounds like it, yes.
Did you follow this guide to create the pdf? https://github.com/jemalloc/jemalloc/wiki/Use-Case:-Leak-Checking
If not, can you try that?
Updated by jeongun baek about 9 years ago
Victor Julien wrote:
Sounds like it, yes.
Did you follow this guide to create the pdf? https://github.com/jemalloc/jemalloc/wiki/Use-Case:-Leak-Checking
If not, can you try that?
hmmm... I'm very confused.
The memory leak was not occured when starting suricata with the following command.
MALLOC_CONF=prof_leak:true,lg_prof_sample:0 LD_PRELOAD=/opt/jemalloc-prof/lib/libjemalloc.so.1 suricata --pfring --pfring-cl uster-id 0 --pfring-cluster-type=cluster_flow -c /usr/local/etc/suricata/suricata.40g.zc.yaml -v
but, the following command causes the memory leak.
LD_PRELOAD=/opt/jemalloc-prof/lib/libjemalloc.so suricata --pfring --pfring-cluster-id 0 --pfring-cluster-type=cluster_flow -c /usr/local/etc/suricata/suricata.40g.zc.yaml -v
Updated by Victor Julien about 8 years ago
- Status changed from New to Closed
- Assignee set to Victor Julien
- Target version set to 3.0.1
We fixed some issues in 3.0.1 and libhtp 0.5.19