lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Bug in ST-provided packet-pump ST32F4xxx ethernetif.c ??


From: Dave Nadler
Subject: [lwip-users] Bug in ST-provided packet-pump ST32F4xxx ethernetif.c ??
Date: Tue, 19 Mar 2019 18:09:35 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3

Correction on priorities! Delete prior message...

I think this is the bug Sergio referred to?
The "CubeMX" framework generates code to connect LwIP to the ST driver.
It appears to free a pbuf before it is processed; seems like a rather bad idea.
What's the proper way to handle this? Or am I confused?

tcpip_thread (lwip) thread priority is set to 3 (FreeRTOS priority 0, which is lowest).
The packet-pump thread ethernetif_input is set to the same priority,
so putting a message into its queue does not immediately trigger
a priority-induced context switch (which would be a non-ideal
way to fix this problem).

Thanks again for any help,
Best Regards, Dave

void ethernetif_input( void const * argument )
{
  struct pbuf *p;
  struct netif *netif = (struct netif *) argument;
  for( ;; )
  {
    if (osSemaphoreWait( s_xSemaphore, TIME_WAITING_FOR_INPUT)==osOK) // DRN: Wait until driver signals one or more frames received
    {
      do
      {  
        p = low_level_input( netif ); // DRN: retrieve next pbuf from driver layer
        if   (p != NULL)
        {
          // DRN: below calls LwIP tcpip_input, which calls tcpip_inpkt, who enqueues msg with pointer p into sys_mbox_t tcpip_mbox
          if (netif->input( p, netif) != ERR_OK )
          {
            pbuf_free(p); // DRN: Serious bug! p is placed in mailbox by netif->input and may not yet have been processed!
          }
        }
      } while(p!=NULL);
    }
  }
}

-- 
Dave Nadler, USA East Coast voice (978) 263-0097, address@hidden, Skype 
 Dave.Nadler1

reply via email to

[Prev in Thread] Current Thread [Next in Thread]