LWIP and tiva-tm4c129.c NETIF abstraction layer frees PBUF during RX frame process and or after the packet data is transferred up the layers to the application. ASSERT_FAIL does not always indicate we have a failure and at times is an informative message as to what is going on in LWIP such as LWIP_TRACE. Here we choose to name the LWIP debug message print out ASSERT_DEBUG.
What if the expected RX frame queued PBUF is never RX back in the http response to the client or is invalid http header data format? The Ethernet client issues (pbuf_free(p)) and LWIP ASSERT checks if (p != NULL) and simply returns as the PBUF is believed NULL. Appears like a slow memory leak and has been found to eventually fill the HEAP memory space almost to the maximum leaving very little space for allocating new PBUF in the abstraction layer. So we end up with a huge amount of PBUF broken chains without any pointers to them in SRAM (HEAP). Hence we can not clear the heap (mem_free) but only for the last few PBUF that may have been ok.
Application layer response to a queued PBUF for Payload of corrupted, missing or partial RX (http) header other than 204 response.
Upon subsequent pbuf_free() clear the corrected ASSERT PBUF pointer (p != NULL) returned. The confusion is if P=NULL we return and display Assert message only when ! p != NULL and still return 0 non the less if p = NULL. Presumably http 0 infers no ACK was returned from the host so then to the (Matching) ACK Pbuf is missing.
exoHAL: << pcBuffer: Read Timeout >>
<< IOT Write (EXO_STATUS_END: Code 10 - http:0) >>
<< [Exosite_Write] No Response >>ASSERT_DEBUG at line 626 of C:/lwip-1.4.1/src/core/pbuf.c: p == NULL
Queued RX PBUF is perceived NULL.
--- what say the LWIP group?
(pbuf.c):
pbuf_free(struct pbuf *p)
{
u16_t type;
struct pbuf *q;
u8_t count;
if (p == NULL) {
LWIP_ASSERT("p != NULL", p != NULL);
/* if assertions are disabled, proceed with debug output */
LWIP_DEBUGF(PBUF_DEBUG | LWIP_DBG_LEVEL_SERIOUS,
("pbuf_free(p == NULL) was called.\n"));
return 0;
}
