[lwip-devel] Re: [patch #7088] DNS with custom malloc/realloc contains a double free in RAM pbuf realloc

[address@hidden]

Ken Smith wrote:
> Our memory allocator provides a working realloc, so in mem.h, we changed
> [..]
> From the sound of it, this violates a critical constraint of lwIP and 
> we should not be doing this
Exactly. After all, not defining mem_realloc to realloc with 
MEM_LIBC_MALLOC==1 has a reason!
> though it begs the question as to why lwIP requires nonstandard 
> behavior from realloc but can accept the standard behavior of the 
> other allocation functions.
Because realloc uses memcpy() when moving data, which is not acceptable 
on most platforms, since it can slow down the stack significantly. Also, 
you don't gain much: pbuf_realloc is not influenced (as you stated 
below) and on the TX side, the packet is freed an instance later, 
anyway, after it has been sent.
> If I'm not mistaken, the call to pbuf_realloc you cite in ip_input is 
> dealing with a pbuf from one of the pools.  At least in my 
> application, our system level realloc is called only for RAM pbufs, 
> never for pool pbufs, so I believe the behavior is correct.
You're right on this. Although by this, ip_input would rely on the netif 
driver to allocate PBUF_POOL pbufs, which can't really be ensured...
> As for the performance impact, again, those other pbufs you mention 
> are not RAM pbufs, but pool pbufs and are reallocated without an 
> actual call to the system level realloc.
Right again, but it also relies on knowing how the netif driver 
allocates pbufs. I know the example ethernetif uses PBUF_POOL and we 
encourage everyone to do so, too, but (at least that's what I think) the 
stack should still work with PBUF_RAM input packets...

Simon