Bug #1367
closed
the memory allocated by libhtp was not freed.
Added by jeongun baek over 9 years ago.
Updated about 8 years ago.
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
|
w.pdf (15.8 KB)
w.pdf |
jemalloc call graph |
jeongun baek, 01/20/2015 07:54 AM
|
|
This is a regular call graph, correct? Any way to get a specific report about the leaks you're seeing?
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 ?
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
- 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
Also available in: Atom
PDF