http_client free pbuf in callbacks

[anatol-newton]

Free pbufs after they were used in multiple callbacks:
http_client_header_print_fn and http_client_receive_print_fn are example callbacks, that print the received data. The buffers should be freed afterwards, as they are not further used,

internal_header_fn is the internal function, that later calls a user callback. Only free the pbuf if no user callback is called. When a user callback is called, the freeing has to take place in there.

If the buffers are not freed, the MCU will eventually run out of RAM (in my application where I found the issue this occurred already after about twelve requests)

[peterharperuk]

Do you have an example that demonstrates the problem? I'm not convinced. pbuf_free is called in internal_recv_fn.
I changed the code to call http_client_request_sync 100 times and it worked ok.

[JeanMax]

Hello!

I agree we miss a call to pbuf_free somewhere.
A fix was proposed here in #605, but nothing as been merged as far as I can tell.

You can check the call to the recv callback in lwip here:
https://github.com/lwip-tcpip/lwip/blob/master/src/apps/http/http_client.c#L350

Notice how a call to pbuf_free is done if no recv callback is supplied.

But I don't think we should call pbuf_free in each of the example_http_client_util.c callbacks, as it will be applied to the same pbuf: both headers_done and recv are handled sequentially in httpc_tcp_recv (the lwip fun I just linked above).

Now I'm wondering if we miss a altcp_recved(conn, p->tot_len) too? :|

Edit: I just did a checkout develop, and now I see why @peterharperuk says the pbuf_free is already in internal_recv_fn ... there is also the altcp_recved hahaha!
Sorry about that, cheers

[peterharperuk]

A leak was fixed in this commit on the develop branch d3c4bac