Failed assertion after receiving two packets

Hi *,

I am transmitting data from various IEEE 802.15.4 nodes. When two packets are received close to each other, an assertion fails:

2017-12-18 09:05:32,821 - INFO # Contents: 'Hello from 1 (94)' 2017-12-18 09:05:32,836 - INFO # Contents: 'Hello from 4 (526)' 2017-12-18 09:05:32,868 - INFO # sys/net/gnrc/pktbuf_static/gnrc_pktbuf_static.c:230 => n/a 2017-12-18 09:05:32,868 - INFO # *** RIOT kernel panic: 2017-12-18 09:05:32,886 - INFO # FAILED ASSERTION. 2017-12-18 09:05:32,887 - INFO # 2017-12-18 09:05:32,932 - INFO # pid | name | state Q | pri | stack ( used) | base addr | current
2017-12-18 09:05:32,980 - INFO # 1 | idle | pending Q | 15 | 768 ( 88) | 0x1eb7 | 0x2174 2017-12-18 09:05:33,028 - INFO # 2 | main | bl mutex _ | 7 | 768 ( 246) | 0x21b7 | 0x23c7 2017-12-18 09:05:33,076 - INFO # 3 | at86rf2xx | bl rx _ | 2 | 512 ( 242) | 0x3de3 | 0x3f44 2017-12-18 09:05:33,124 - INFO # 4 | dump_thread | running Q | 8 | 768 ( 766) | 0x1b49 | 0x1dea 2017-12-18 09:05:33,171 - INFO # 5 | send_thread | bl mutex _ | 9 | 768 ( 170) | 0x1809 | 0x1a6d 2017-12-18 09:05:33,204 - INFO # | SUM | | | 3584 ( 1512) 2017-12-18 09:05:33,205 - INFO # 2017-12-18 09:05:33,205 - INFO # *** halted. 2017-12-18 09:05:33,219 - INFO #

The assertion that fails is:

assert(pkt->users > 0);

The application runs fine when packets are received separately. However, if there is more than one packet in the buffer (that's what I suspect right now), my application fails. The applications code is attached. Any one having an idea why this fails? Is the application correct? Maybe some mutex is failing low-level-ish? Maybe threading on my node (based on atmega1284p and atmega_common cpu) is corrupted?

Best Regards, Robert

main.c (6.04 KB)

Makefile (433 Bytes)

Hi Robert,

Done, https://github.com/RIOT-OS/RIOT/issues/8271

Will update shortly with more information.

Hi,

if I find some time tomorrow, I will investigate this (I don’t have any supported AVR platform however :-/, so I might only be able to confirm that it is an AVR problem, not however what causes it).

Cheers, Martine