[VPP-1240] NAT memory leak - identity mapping fo GbE IP

[vvalderrv]

Description

Hi Matus,

 

We tried to add the identity mapping for GbE IP (192.168.16.10 in my case) over the binary API, but VPP will always crash after just few seconds of runtime:

Backtrace:

 

#0  0x00007f301f6dc428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54

#1  0x00007f301f6de02a in __GI_abort () at abort.c:89

#2  0x0000000000406a24 in os_panic () at /home/mlenco/dev/vpp/build-data/../src/vpp/vnet/main.c:268

#3  0x00007f301ff7148d in os_out_of_memory () at /home/mlenco/dev/vpp/build-data/../src/vppinfra/unix-misc.c:221

#4  0x00007f301ff4e90f in clib_mem_alloc_aligned_at_offset (size=568693920, align=4, align_offset=4,

    os_out_of_memory_on_failure=1) at /home/mlenco/dev/vpp/build-data/../src/vppinfra/mem.h:105

#5  0x00007f301ff4ed26 in vec_resize_allocate_memory (v=0x7f30009c57a0, length_increment=1, data_bytes=379129288,

    header_bytes=4, data_align=4) at /home/mlenco/dev/vpp/build-data/../src/vppinfra/vec.c:84

#6  0x00007f3020f9fd5a in _vec_resize (v=0x7f30009c57a0, length_increment=1, data_bytes=379129284, header_bytes=0,

    data_align=0) at /home/mlenco/dev/vpp/build-data/../src/vppinfra/vec.h:142

#7  0x00007f3020fa38c8 in vlib_put_next_frame (vm=0x7f3021246480 <vlib_global_main>, r=0x7f2fe0293c80,

    next_index=2, n_vectors_left=255) at /home/mlenco/dev/vpp/build-data/../src/vlib/main.c:501

#8  0x00007f302045a83e in ip4_lookup_inline (vm=0x7f3021246480 <vlib_global_main>, node=0x7f2fe0293c80,

    frame=0x7f2fe0316ac0, lookup_for_responses_to_locally_received_packets=0)

    at /home/mlenco/dev/vpp/build-data/../src/vnet/ip/ip4_forward.c:420

#9  0x00007f302045a8e6 in ip4_lookup (vm=0x7f3021246480 <vlib_global_main>, node=0x7f2fe0293c80,

    frame=0x7f2fe0316ac0) at /home/mlenco/dev/vpp/build-data/../src/vnet/ip/ip4_forward.c:465

#10 0x00007f3020fa4ca4 in dispatch_node (vm=0x7f3021246480 <vlib_global_main>, node=0x7f2fe0293c80,

    type=VLIB_NODE_TYPE_INTERNAL, dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f2fe0316ac0,

    last_time_stamp=230993216616) at /home/mlenco/dev/vpp/build-data/../src/vlib/main.c:988

#11 0x00007f3020fa525d in dispatch_pending_node (vm=0x7f3021246480 <vlib_global_main>,

    pending_frame_index=31594105, last_time_stamp=230993216616)

    at /home/mlenco/dev/vpp/build-data/../src/vlib/main.c:1138

#12 0x00007f3020fa7439 in vlib_main_or_worker_loop (vm=0x7f3021246480 <vlib_global_main>, is_main=1)

    at /home/mlenco/dev/vpp/build-data/../src/vlib/main.c:1609

#13 0x00007f3020fa74e7 in vlib_main_loop (vm=0x7f3021246480 <vlib_global_main>)

    at /home/mlenco/dev/vpp/build-data/../src/vlib/main.c:1628

#14 0x00007f3020fa7d5d in vlib_main (vm=0x7f3021246480 <vlib_global_main>, input=0x7f2fe012ffb0)

    at /home/mlenco/dev/vpp/build-data/../src/vlib/main.c:1783

#15 0x00007f302100ed11 in thread0 (arg=139844691190912)

    at /home/mlenco/dev/vpp/build-data/../src/vlib/unix/main.c:567

#16 0x00007f301fee6dc4 in clib_calljmp () at /home/mlenco/dev/vpp/build-data/../src/vppinfra/longjmp.S:110

#17 0x00007ffd63ccdb00 in ?? ()

#18 0x00007f302100f172 in vlib_unix_main (argc=17, argv=0x2570010)

    at /home/mlenco/dev/vpp/build-data/../src/vlib/unix/main.c:631

#19 0x000000000040670c in main (argc=17, argv=0x2570010)

    at /home/mlenco/dev/vpp/build-data/../src/vpp/vnet/main.c:207

  

Attached is compressed full core dump, api post-mortem dump and a screenshot of installed mappings, captured quickly just before VPP had crashed.

It appears the VPP had crashed in ip4-lookup with OOM. Without that extra identity mapping the VPP runs OK, so perhaps a memory leak in the NAT plugin?

VPP version: vpp-dev/vpp@88bfc1e

 

Thanks,

Milan

Assignee

Matus Fabian

Reporter

Viera Zelcamova

Comments

• matfabia (Fri, 20 Apr 2018 14:42:51 +0000): No further memory leaks issues in NAT plugin. Memory usage is slowly growing also without NAT plugin configured when using STN setup.

Original issue: https://jira.fd.io/browse/VPP-1240

[vvalderrv]

No further memory leaks issues in NAT plugin. Memory usage is slowly growing also without NAT plugin configured when using STN setup.