Re: [lwip-users] http server and pbuf overflow

[Simon Goldschmidt]

p == NULL is perfectly normal and tells your application that the remote side 
has sent a FIN. However, this should not lead to memory- or pbuf leaks... I'll 
see if I can reproduce that.

Simon


"Bernhard \'Gustl\' Bauer" wrote:
> address@hidden schrieb:
> > tcp_abort currently shouldn't be used from one of the callback 
> > functions: http://savannah.nongnu.org/bugs/?27871
> > 
> > Can you try replacing that with tcp_close(); and return ERR_OK;? In any 
> > case, calling tcp_recved() won't hurt, too. (Although before tcp_abort, 
> > it shouldn't be necessary - once the above bug is fixed.)
> 
> I did this. But the problem still exists. I checked again all exit 
> points and recognized that sometimes http_recv is called with p=NULL; !! 
> This happens when remote sends a TCP retransmission, or a FIN because of 
> a corrupt transfer. This is my shortened function:
> 
> static err_t
> http_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err)
> {
>    char *data;
>    char *data1;
>    struct http_state *hs;
> 
>    hs = arg;
> 
>    if (err == ERR_OK && p != NULL) {
> 
> ...
> 
>    }
> 
>    if (err == ERR_OK && p == NULL) {
>      close_conn(pcb, hs);             
>    }
>    return ERR_OK;
> }
> 
> If p=NULL was caused by a FIN the pbuf containing this FIN is never 
> freed! See port number 4784 in attached pcap.
> 
> What can I do about this?
> 
> Gustl
> 
> 
> 
> 

-- 
Haiti-Nothilfe! Helfen Sie per SMS: Sende UIHAITI an die Nummer 81190.
Von 5 Euro je SMS (zzgl. SMS-Gebühr) gehen 4,83 Euro an UNICEF.