Re: [lwip-users] questions on lwip (two TCP/IP sockets)

[David Empson]

Simon Goldschmidt <address@hidden> wrote:
>  Kieran Mansley wrote:
> > On 12 Aug 2010, at 20:16, Jeff Barber wrote:
> >
> > > I'd like to see someone more authoritative (like Simon or Kieran?)
> > > weigh in on this but I'm pretty sure that the advice you cited is just
> > > plain wrong.
> > Yes, it's very wrong.  It may once have been true in the dim past,
> Hmm, "dim past"... that post seems to be only less than 2 months old, 
> however, I don't remember having read it or I would have told the author 
> that it's wrong...

It wasn't posted to an lwip mailing list, but to a ti.com forum, so you can 
be forgiven for not having seen it.

I suspect the actual bug in the forum posting was the missing tcp_recved() 
call. The looped pbuf_free() code is dangerous for all the reasons cited 
here.

> >   but even so it references memory after it was freed
> And that's the point at which I'm really confused: Either our 
> documentation is really really bad or the author of that post should first 
> start programming with something easier than lwIP... accessing freed 
> memory seems like a beginner's mistake to me (sorry if this sounds rude!), 
> and (unfortunately) lwIP is a bit more complicated to handle than a simple 
> "hello world" example :-(

The worrying part is that a TI employee in responding to the question 
claimed a simple call to pbuf_free() would leak memory if there was a chain 
of pbufs, recommended freeing each pbuf in the chain separately, and 
confirmed the resulting code. That suggestion is now shown in the forum as a 
verified answer. How many other people have or will be misled?

The implementation is of course wrong in many ways, but there can be no 
"right" way of calling pbuf_free() in a loop for each pbuf in the chain: 
assuming a reference count of 1, even if p->next had been copied elsewhere 
prior to calling pbuf_free(p), it would no longer be valid afterwards, 
because the chained pbuf (if any) was already freed. The next call in the 
loop would be trying to free an already freed pbuf (and referencing a 
possibly invalid p->next pointer for all subsequent pbufs). If the reference 
count was higher, then this code would free part of a pbuf chain still being 
used elsewhere, leaving dangling pointers into free memory.

This is the sort of bug which might hide and bite you only in unusual 
circumstances, because most of the time the receive callback will be dealing 
with a single pbuf.

Unless of course TI's EDK has a modified pbuf_free() which really does 
behave the way described, completely changing its meaning and affecting 
portability of code to/from any other LWIP port.

(Shudder)

Someone who actually uses that EDK should confirm the details and post a 
followup on that forum pointing out the error.