Thank you Dave. I tried disabling history ( which caused a crash ). So, I used 
to gdb to avoid the problematic code for the time being.
With this, now, I am not seeing periodic increments in the traced allocations 
due to CLI history.

However, I am still not getting how to make good use of the "show memory 
verbose" o/p to find a leak.
The o/p is not removing the entries that were freed, which is bit confusing.

For ex:

1) With clean slate
traced object are 1.

Thread 0 vpp_main
virtual memory start 0x7fffb4c86000, size 1048640k, 262160 pages, page size 4k
numa 0: 15708 pages, 62832k
not mapped: 0 pages, 0k
unknown: 246452 pages, 985808k
total: 1.00G, used: 62.03M, free: 962.03M, trimmable: 958.59M
free chunks 79 free fastbin blks 0
max total allocated 1.00G

1 total traced objects

2) Now, I have added one ip table
traced objects became 26

Thread 0 vpp_main
virtual memory start 0x7fffb4c86000, size 1048640k, 262160 pages, page size 4k
numa 0: 15708 pages, 62832k
not mapped: 0 pages, 0k
unknown: 246452 pages, 985808k
total: 1.00G, used: 62.04M, free: 962.02M, trimmable: 958.59M
free chunks 78 free fastbin blks 0
max total allocated 1.00G

Bytes    Count     Sample   Traceback
1920        1 0x7fffb8645eb0 clib_mem_alloc_aligned_at_offset + 0x86
vec_resize_allocate_memory + 0x199
_vec_resize_inline + 0x136
mfib_entry_alloc + 0x1c4
mfib_entry_create + 0x3d
mfib_table_entry_update + 0x7f
ip4_create_mfib_with_table_id + 0x3de
ip4_mfib_table_find_or_create_and_lock + 0x3f
mfib_table_find_or_create_and_lock_i + 0x44
mfib_table_find_or_create_and_lock_w_name + 0x3b
ip_table_create + 0xb6
vnet_ip_table_cmd + 0x1ff

26 total traced objects

3) Now , I deleted the same ip table
traced objects became 37. This really confused me. After deletion, the traced 
object should come down way below than 26 objects , right ?
How come it increased from 26 to 27. I could see the deallocation stack traces 
also in the output. But, how can we map each allocation to a deallocation and 
detect it as a leak ? Do we need to manually go through each stack trace and do 
this ?

Thread 0 vpp_main
virtual memory start 0x7fffb4c86000, size 1048640k, 262160 pages, page size 4k
numa 0: 15708 pages, 62832k
not mapped: 0 pages, 0k
unknown: 246452 pages, 985808k
total: 1.00G, used: 62.05M, free: 962.02M, trimmable: 958.59M
free chunks 66 free fastbin blks 0
max total allocated 1.00G

Bytes    Count     Sample   Traceback
1920        1 0x7fffb8645eb0 clib_mem_alloc_aligned_at_offset + 0x86
vec_resize_allocate_memory + 0x199
_vec_resize_inline + 0x136
mfib_entry_alloc + 0x1c4
mfib_entry_create + 0x3d
mfib_table_entry_update + 0x7f
ip4_create_mfib_with_table_id + 0x3de
ip4_mfib_table_find_or_create_and_lock + 0x3f
mfib_table_find_or_create_and_lock_i + 0x44
mfib_table_find_or_create_and_lock_w_name + 0x3b
ip_table_create + 0xb6
vnet_ip_table_cmd + 0x1ff

I see some deallocation stack traces.

37 total traced objects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15278): https://lists.fd.io/g/vpp-dev/message/15278
Mute This Topic: https://lists.fd.io/mt/70214211/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to