[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] fix assert triggered in tcp_in.c

From: Pedro Alves
Subject: Re: [lwip-users] fix assert triggered in tcp_in.c
Date: Fri, 07 Apr 2006 17:15:41 +0100
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Christiaan Simons wrote:

Pedro Alves wrote:

Yep, that's right. Any change of getting it into cvs?

I'm not sure if this is 100% correct.

pbuf_free() does not guarantee the pbuf-chain is fully freed,
it may also lower some reference counters, or free the chain partially.
Sometimes multiple calls to pbuf_free in a loop maybe required.
Setting the pointer to NULL without checking the return value
of pbuf_free might actually result in a leak.

Maybe the actual problem is in where an assumption/evaluation
is made on the pointer value where it is used.

The test app I was using was opening a socket (raw api) to a listenning server on a pc, and sending data as fast is it could checking for
out buffer space before sending. This was done inside the send event.
The server never sends any (app level) bytes whatsoever.

The assert was showing up in that same pbuf_free call after checking for inseg.p != NULL.
   if (inseg.p != NULL) pbuf_free(inseg.p); <-- Here.

It says on the comment just before my patch:

   /* We deallocate the incoming pbuf. If it was buffered by the
      application, the application should have called pbuf_ref() to
      increase the reference counter in the pbuf. If so, the buffer
      isn't actually deallocated by the call to pbuf_free(), only the
      reference count is decreased. */
So lwip doesn't care anymore about that pbuf. It should be safe to clear inseg.p, no?

Christiaan Simons

Hardware Designer
Axon Digital Design


lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]