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 highest).
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, d...@nadler.com, Skype
Dave.Nadler1
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
