gnrc_netif_pktq leaks memory #17924
Comments
benpicco
added
Type: bug
|
I have seen these issues in the past with the gnrc_netif/submac integration.. With the last commits that should have been fixed. |
|
Which "last commits" are you referring to? |
|
It also happens with DOSE, but I think a second interface was required to trigger this (will try to reproduce this with a single one) |
z.B #16964 |
I think this could be an effect of having two interfaces running with the same priority. Considering that |
Mh, I don't have that board and trying to reproduce with |
@benpicco could you try if running the interfaces at different |
Can you use it together with
Why would it, the debugger exposes a |
Then IARW (I apparently remembered wrong) ;-) |
I don't get an immediate |
|
It's not immediate, it takes several minutes, I don't have found a quick way yet to trigger the condition. |
|
Can you confirm, that after the first execution of From just a quick scan, I think that's at least one response from the host: the start of chunk1 looks like an IPv6 header with two link local unicast addresses. Since I pinged multicast, it can't be the echo request, and the source and destination addresses confirm that this comes from the host. If this is indeed the case for you as well, I don't believe, its |
|
I'm afraid this might not be related to I have a board with a SLIP and an There is no My suspicion is with a fragmentation issue, as small snips can still be allocated (the data that is received / sent makes use of large (~1k) frames). |
Is it possible to provide a dump of |
|
I now have a quite reliable way to trigger the condition, requires sending on one interface while also receiving data on a another interface. pktbuf remains full after I stop the sending board . I've added #18102 for dual-entry bookkeeping, result is I'm not quite sure what to make out of that though. |
|
I've added some more tracing to also log the place where the pktbuf allocation was made
(I switched from |
|
Ok, this turns out to be an unrelated issue. The sending thread did not call This can be solved by calling while (sock_udp_recv(&sock, buf, sizeof(buf), 0, NULL) > 0) {}after every |
So the test application is no longer relevant? |
|
In case of /* hold in case device was busy to not having to rewrite *all* the link
* layer implementations in case `gnrc_netif_pktq` is included */
gnrc_pktbuf_hold(pkt, 1);It holds the full packet (gnrc netif header + icmp + ipv6 header + ...) Then we pass the packet to the netif send operation int res = netif->ops->send(netif, pkt);which in case of if (pkt->type == GNRC_NETTYPE_NETIF) {
/* we don't need the netif snip: remove it */
pkt = gnrc_pktbuf_remove_snip(pkt, pkt);
}In gnrc_pktsnip_t *gnrc_pktbuf_remove_snip(gnrc_pktsnip_t *pkt,
gnrc_pktsnip_t *snip)
{
pkt = gnrc_pkt_delete(pkt, snip);
snip->next = NULL;
gnrc_pktbuf_release(snip);
return pkt;
}The netif driver deletes the remaining packet snips after the netif header, after sending res = dev->driver->send(dev, (iolist_t *)pkt);
if (gnrc_netif_netdev_legacy_api(netif)) {
/* only for legacy drivers we need to release pkt here */
gnrc_pktbuf_release(pkt);
}Back in if (gnrc_netif_netdev_new_api(netif)) {
/* with new netdev (with confirm_send), the netif remains owner of the
* pkt and is in charge of releasing it once TX is completed */
gnrc_pktbuf_release_error(pkt, err);
}But here |
|
We could maybe prohibit to remove a packet snip which is not the first snip in the chain. |
|
Hm but |
|
Sorry, then it was in the |
|
This still happens with the border router app. The packet buffer keeps filling up and after a short while the border router is no longer able to send any packets. gnrc_pktbuf_stats() |
Description
Steps to reproduce the issue
Use
gnrc_netif_pktqon a board with two interfaces (e.g.nrf802154&slipdev) e.g. by runningExpected results
The node can send and receive packets.
Actual results
After a few minutes the node can no longer send any packets
The node never recovers until it is rebooted.
Versions
RIOT master
The text was updated successfully, but these errors were encountered: