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

Sebastian Gonzalez Fri, 31 May 2013 01:44:46 -0700

  
    
  
  
    Dear Ivan, 
    
    The issue that you mention is already covered in the latest example
    from Atmel, see code below. 
    After reviewing my code I noticed that all sockets are opened and
    closed as thery are used, all but an UDP socket that remained open
    continuously, used to receive broadcast frames, I am now closing
    this socket and reopening it every 30 seconds if no frames are
    received, this operation releases any memory that could be stuck in
    the deadlock. Looks good so far. 
    I'll let the system the system under test this weekend. 
    
    Thanks. 
    
    &nbsp;&nbsp;&nbsp; switch( htons( ethhdr-&gt;type ) ) 
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; /* IP or ARP 
packet? */ 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; case 
ETHTYPE_IP: 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; case 
ETHTYPE_ARP: 
    #if PPPOE_SUPPORT 
    &nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; /* PPPoE 
packet? */ 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; case 
ETHTYPE_PPPOEDISC: 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; case 
ETHTYPE_PPPOE: 
    #endif /* PPPOE_SUPPORT */ 
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
/* full packet send to tcpip_thread to process
    */&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; if( xNetIf-&gt;input(p, xNetIf) != ERR_OK ) 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; { LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP
    input error\n")); 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; pbuf_free(p); 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; p = NULL; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; } 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
break;&nbsp; &nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; default: 
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
pbuf_free( p ); 
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
p = NULL; 
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
break; 
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; 
    El 30/05/2013 19:10, Ivan Delamer-2
      [via lwIP] escribi&oacute;: 
    
     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-&gt;input
      
      
      I have this code:
      
      
      &nbsp; &nbsp; &nbsp;switch( htons( ethhdr-&gt;type ) )
      
      &nbsp; &nbsp; &nbsp;{
      
      &nbsp; &nbsp; &nbsp; &nbsp;/* IP packet? */
      
      &nbsp; &nbsp; &nbsp; &nbsp;case ETHTYPE_IP:
      
      &nbsp; &nbsp; &nbsp; &nbsp;case ETHTYPE_ARP:
      
      &nbsp; &nbsp; &nbsp; &nbsp;case ETHTYPE_IPV6:
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/* pass to network layer */
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (pxNetIf-&gt;input( p, pxNetIf ) != 
ERR_OK)
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;{
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pbuf_free( p );
      
      #if LINK_STATS
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;lwip_stats.link.drop++;
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;lwip_stats.link.err++;
      
      #endif /* LINK_STATS */
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;break;
      
      
      &nbsp; &nbsp; &nbsp; &nbsp;default:
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pbuf_free( p );
      
      #if LINK_STATS
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;lwip_stats.link.drop++;
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;lwip_stats.link.proterr++;
      
      #endif /* LINK_STATS */
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;p = NULL;
      
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;break;
      
      &nbsp; &nbsp; &nbsp; &nbsp;}
      
      
      The key is to free the pbuf not only if packet type is
      unrecognized, 
      but also if pxNetIf-&gt;input fails (this is where I had my memory
      leak).
      
      
      Cheers
      
      Ivan
      
      
        &gt; Date: Thu, 30 May 2013 02:14:04 -0700 (PDT)
        
        &gt; From: Sebastian Gonzalez &lt; [hidden email] &gt;
        
        &gt; To: [hidden email] 
        
        &gt; Subject: Re: [lwip-users] Receive path stuck due to
        pbuf_alloc
        
        &gt; returning NULL
        
        &gt; Message-ID: &lt; [hidden email] &gt;
        
        &gt; Content-Type: text/plain; charset=us-ascii
        
        &gt; 
        &gt; Hi,
        
        &gt; 
        &gt; I am still having problems, but it's true that it takes
        more time for 
        &gt; the
        
        &gt; system to stop receiving under the same stress tests.
        
        &gt; I made a little test that includes a semaphore that is set
        everytime a 
        &gt; pbuf
        
        &gt; is allocated and is released every time the packet is
        processed, but 
        &gt; with no
        
        &gt; positive results. Wether not every pbuf is freed in the
        TCP/IP thread 
        &gt; after
        
        &gt; being processed, or there is a memory leak as Ivan
        sugested.
        
        &gt; Is there any way to release all the memory? I don't mind
        having to 
        &gt; close my
        
        &gt; application sockets if the system is restored and I can
        reopen them.
        
        &gt; 
        &gt; Thanks.
        
        &gt; 
        &gt; Sebestian.
      
      
      
      _______________________________________________
      
      lwip-users mailing list
      
      [hidden email] 
      
      https://lists.nongnu.org/mailman/listinfo/lwip-users 
      
      
      
      
        If you reply to this email, your
          message will be added to the discussion below: 
        
http://lwip.100.n7.nabble.com/Receive-path-stuck-due-to-pbuf-alloc-returning-NULL-tp21461p21490.html
 
      
      
        To unsubscribe from Receive path stuck due to pbuf_alloc
        returning NULL, click
          here . 
        NAML  
    
    
    -- 
      
        Firma By
           
        Sebasti&aacute;n Gonz&aacute;lez 
          Investigaci&oacute;n y Desarrollo 
          Tlf: 902 82 00 82 
          Fax: 902 82 00 83 
          
          [email protected] 
          www.by.com.es 
        
         
          Antes de imprimir este e-mail piense si realmente es necesario
          hacerlo, el medio ambiente se lo agradecer&aacute;. 
          
            ADVERTENCIA 
                La informaci&oacute;n contenida en este correo 
electr&oacute;nico, es
                de car&aacute;cter privado y confidencial, siendo para uso
                exclusivo de su destinatario. Si usted no es el
                destinatario correcto, o ha recibido esta comunicaci&oacute;n
                por error, le informamos que est&aacute; totalmente prohibida
                cualquier divulgaci&oacute;n, distribuci&oacute;n o 
reproducci&oacute;n de
                esta comunicaci&oacute;n seg&uacute;n la legislaci&oacute;n 
vigente y le
                rogamos que nos lo notifique inmediatamente, procediendo
                a su destrucci&oacute;n sin continuar su lectura. 
                Su direcci&oacute;n de correo electr&oacute;nico, as&iacute; 
como el resto de
                los datos de car&aacute;cter personal que nos facilite, 
podr&iacute;an
                ser objeto de tratamiento automatizado en nuestros
                ficheros, con la finalidad de gestionar la agenda de
                contactos de BY TECHDESIGN,S.L. Vd. podr&aacute; en cualquier
                momento ejercer sus derechos de acceso, rectificaci&oacute;n,
                cancelaci&oacute;n y oposici&oacute;n seg&uacute;n la Ley 
Org&aacute;nica 15/1999
                mediante notificaci&oacute;n escrita a la siguiente 
direcci&oacute;n:
                CALLE TOMAS EDISON 5 28500 ARGANDA DEL REY.




LogoBy.jpg (3K) <http://lwip.100.n7.nabble.com/attachment/21494/0/LogoBy.jpg>




--
View this message in context: 
http://lwip.100.n7.nabble.com/Receive-path-stuck-due-to-pbuf-alloc-returning-NULL-tp21461p21494.html
Sent from the lwip-users mailing list archive at Nabble.com.

_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

Reply via email to