Release 2015.09 - RC3

[OlegHahm]

This issue lists the status of all tests for the Release Candidate 3 of the 2015.09 release.

Specs tested:

• 01-CI
• 02-Tests
• 03-Single Hop IPv6 ICMP
• 04-Single Hop 6LoWPAN ICMP
• 05-Single Hop Route
• 06-Single Hop UDP
• 07-Multi Hop
• 08-Interop
  • For Linux testing a patched version of radvd is required, otherwise it won't send the SLLAO in the router advertisements.

[cgundogan]

#5 (comment)

Damn, I can create memory leaks even with just two nodes and unicast pings.

Can you briefly explain how you can enforce memory leaks? Does it only occure on the iotlab?
I was just pinging and dumping the pktbuf on native and the pktbuf is empty as desired

[cgundogan]

Now I tried (unicast, single-hop) pinging on the iotlab testbed. pktbuffer still behaves as expected

[OlegHahm]

Start an experiment with 5 nodes, ping from node to another like this:
ping6 1000 fe80::<EUI64> 1024 0

[cgundogan]

I used my running experiment (2 nodes and gnrc_networking example).

m3-1;ping6 1000 fe80::3432:4833:46de:7d2a 1024 0
...
1443779431.438676;m3-1;1032 bytes from fe80::3432:4833:46de:7d2a: id=103 seq=1000 hop limit=64 time = 137.352 ms
1443779431.439674;m3-1;packet buffer: first byte: 0x20001c78, last byte: 0x20003478 (size: 6144)
1443779431.440674;m3-1;~ unused: 0x20001c78 (next: 0, size: 6144) ~
1443779431.441936;m3-1;--- fe80::3432:4833:46de:7d2a ping statistics ---
1443779431.444009;m3-1;1000 packets transmitted, 999 received, 1% packet loss, time 149.06279990 s
1443779431.444974;m3-1;rtt min/avg/max = 126.339/139.376/153.136 ms

[OlegHahm]

Maybe it's not happening always.

[OlegHahm]

Have you tried with multicast pinging, too?

[cgundogan]

multicast ping leaks memory and after several attempts I get the "pktbuffer full" error on the pinging side

[miri64]

From #5 (comment)

That's bad. I couldn't find a leak even with 5 nodes in 04. How did you test?

I patched the gnrc_networking example to have easy acces to the gnrc_pktbuf_stats() function:

diff --git a/examples/gnrc_networking/main.c b/examples/gnrc_networking/main.c
index 6301f42..24f5405 100644
--- a/examples/gnrc_networking/main.c
+++ b/examples/gnrc_networking/main.c
@@ -20,6 +20,7 @@

 #include <stdio.h>

+#include "net/gnrc/pktbuf.h"
 #include "shell.h"
 #include "msg.h"

@@ -28,8 +29,17 @@ static msg_t _main_msg_queue[MAIN_QUEUE_SIZE];

 extern int udp_cmd(int argc, char **argv);

+static int _pktbuf(int argc, char **argv)
+{
+    (void)argc;
+    (void)argv;
+    gnrc_pktbuf_stats();
+    return 0;
+}
+
 static const shell_command_t shell_commands[] = {
     { "udp", "send data over UDP and listen on UDP ports", udp_cmd },
+    { "pktbuf", "output packet buffer strts", _pktbuf },
     { NULL, NULL, NULL }
 };

And started an experiment with three nodes in the testbed.

BOARD=iotlab-m3 IOTLAB_NODES=3 make iotlab-exp iotlab-term

Then I started the experiment as usual

ping6 1000 ff02::1 0 10

After that I have leaks in the packet buffer (e.g. on current release branch)

1443786149.845414;m3-7;packet buffer: first byte: 0x20001c78, last byte: 0x20003478 (size: 6144)
1443786149.846495;m3-7;~ unused: 0x20001c78 (next: 0x20001d00, size:  124) ~
1443786149.849362;m3-7;================ chunk   0 (size:   12) ================
1443786149.849695;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.849742;m3-7;~ unused: 0x20001d00 (next: 0x20001d40, size:   52) ~
1443786149.850404;m3-7;================ chunk   1 (size:   12) ================
1443786149.852435;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.853286;m3-7;~ unused: 0x20001d40 (next: 0x20001d50, size:    8) ~
1443786149.854278;m3-7;================ chunk   2 (size:    8) ================
1443786149.858872;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.859343;m3-7;~ unused: 0x20001d50 (next: 0x20001e14, size:  188) ~
1443786149.859387;m3-7;================ chunk   3 (size:    8) ================
1443786149.859475;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.859793;m3-7;~ unused: 0x20001e14 (next: 0x20001e2c, size:    8) ~
1443786149.861283;m3-7;================ chunk   4 (size:   16) ================
1443786149.862361;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.863300;m3-7;~ unused: 0x20001e2c (next: 0x20001e40, size:    8) ~
1443786149.865286;m3-7;================ chunk   5 (size:   12) ================
1443786149.866369;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.867425;m3-7;~ unused: 0x20001e40 (next: 0x20001ea0, size:   84) ~
1443786149.868413;m3-7;================ chunk   6 (size:   12) ================
1443786149.870259;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.871314;m3-7;~ unused: 0x20001ea0 (next: 0x20001ecc, size:   32) ~
1443786149.872336;m3-7;================ chunk   7 (size:   12) ================
1443786149.873262;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.874278;m3-7;~ unused: 0x20001ecc (next: 0x20001f04, size:   44) ~
1443786149.876280;m3-7;================ chunk   8 (size:   12) ================
1443786149.877336;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.878421;m3-7;~ unused: 0x20001f04 (next: 0x20001f28, size:   20) ~
1443786149.879342;m3-7;================ chunk   9 (size:   16) ================
1443786149.881281;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.882343;m3-7;~ unused: 0x20001f28 (next: 0x20001f38, size:    8) ~
1443786149.883348;m3-7;================ chunk  10 (size:    8) ================
1443786149.884332;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.887332;m3-7;~ unused: 0x20001f38 (next: 0x20001f58, size:   20) ~
1443786149.887756;m3-7;================ chunk  11 (size:   12) ================
1443786149.888441;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.889281;m3-7;~ unused: 0x20001f58 (next: 0x20002014, size:  156) ~
1443786149.890273;m3-7;================ chunk  12 (size:   32) ================
1443786149.894865;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.895275;m3-7;000010 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.895714;m3-7;~ unused: 0x20002014 (next: 0x200020d4, size:  160) ~
1443786149.896432;m3-7;================ chunk  13 (size:   32) ================
1443786149.898280;m3-7;000000 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.900335;m3-7;000010 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx 0hx
1443786149.901330;m3-7;~ unused: 0x200020d4 (next: 0, size: 5028) ~

(oh and that shorts aren't printed anymore is quite a bummer ;-))

[miri64]

From #5 (comment)

Though the make-up seems to be quite random, the data in them seems to have some system to them. (0x08000000 appears quite often as well as 0x3263eb52 (which is part of the of the nodes MAC address 86:a4:3c:63:eb:52 or link-local IPv6 address fe80::84a4:3cff:fe63:eb52 respectively))

The 0x0008 seems to be the IPv6 length field.

Could be, could also be 0x00000008 and the size field of a packet snip pointing to the ICMPv6 header.

[OlegHahm]

(oh and that shorts aren't printed anymore is quite a bummer ;-))

Since when do you have this problem?

[miri64]

I realized this only yesterday. But it's also effecting ifconfig's output:

1443788535.203990;m3-7;ifconfig
1443788535.205555;m3-7;Iface  7   HWaddr: 7c:2a  Channel: 26  NID: 0x23  TX-Power: 0dBm  State: IDLE CSMA Retries: hu 
1443788535.206540;m3-7;           Long HWaddr: 36:32:48:33:46:d4:7c:2a 
1443788535.207537;m3-7;           AUTOACK  CSMA  MTU:1280  6LO  IPHC  
1443788535.208539;m3-7;           Source address length: 8
1443788535.209816;m3-7;           Link type: wireless
1443788535.210544;m3-7;           inet6 addr: ff02::1/hu  scope: local [multicast]
1443788535.211540;m3-7;           inet6 addr: fe80::3432:4833:46d4:7c2a/hu  scope: local
1443788535.213546;m3-7;           inet6 addr: ff02::1:ffd4:7c2a/hu  scope: local [multicast]
1443788535.213661;m3-7;           

[cgundogan]

and rpl's output for the trickle timer values

[cgundogan]

I realized it 1-2 weeks ago, but I forget about it and thought it was merely a problem with my compiler

[OlegHahm]

I have this for the rpl output, but not for od or ifconfig.

[OlegHahm]

And I think for RPL it is related to RIOT-OS/RIOT#1891

[miri64]

I think for od and ifconfig this is toolchain and nano.specs related.

[OlegHahm]

Superseded by #7