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: > [email protected] 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. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
