Re: [lwip-users] Receive path stuck due to pbuf_alloc ret urning NULL

[Ivan Delamer]

I don't know if this still applies but a while ago there was a memory 
leak in the AT91/FreeRTOS implementation of ethernetif_input() when 
passing the pbuf to netif->input

I have this code:

    switch( htons( ethhdr->type ) )
    {
      /* IP packet? */
      case ETHTYPE_IP:
      case ETHTYPE_ARP:
      case ETHTYPE_IPV6:
        /* pass to network layer */
        if (pxNetIf->input( p, pxNetIf ) != ERR_OK)
        {
          pbuf_free( p );
#if LINK_STATS
          lwip_stats.link.drop++;
          lwip_stats.link.err++;
#endif /* LINK_STATS */
        }
        break;

      default:
        pbuf_free( p );
#if LINK_STATS
        lwip_stats.link.drop++;
        lwip_stats.link.proterr++;
#endif /* LINK_STATS */
        p = NULL;
        break;
      }

The key is to free the pbuf not only if packet type is unrecognized, 
but also if pxNetIf->input fails (this is where I had my memory leak).

Cheers
Ivan

> Date: Thu, 30 May 2013 02:14:04 -0700 (PDT)
> From: Sebastian Gonzalez <address@hidden>
> To: address@hidden
> Subject: Re: [lwip-users] Receive path stuck due to pbuf_alloc
>         returning NULL
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> I am still having problems, but it's true that it takes more time for 
> the
> system to stop receiving under the same stress tests.
> I made a little test that includes a semaphore that is set everytime a 
> pbuf
> is allocated and is released every time the packet is processed, but 
> with no
> positive results. Wether not every pbuf is freed in the TCP/IP thread 
> after
> being processed, or there is a memory leak as Ivan sugested.
> Is there any way to release all the memory? I don't mind having to 
> close my
> application sockets if the system is restored and I can reopen them.
>
> Thanks.
>
> Sebestian.