RE: [lwip-users] Installed the new version, since allthechangesandturned on the ASSERT debug

[Kieran Mansley]

On Tue, 2007-03-20 at 16:13 +0000, Joolz [RSD] wrote:
>  
> -----Original Message-----
> From: Kieran Mansley [mailto:address@hidden 
> Sent: 20 March 2007 16:12
> To: Mailing list for lwIP users
> Subject: RE: [lwip-users] Installed the new version, since
> allthechangesandturned on the ASSERT debug
> 
> On Tue, 2007-03-20 at 15:45 +0000, Joolz [RSD] wrote:
> > Do I need to free the data, I thought that would be done by the 
> > udp_send
> 
> >From doc/rawapi.txt:
> >>- err_t udp_send(struct udp_pcb *pcb, struct pbuf *p)
> >> Sends the pbuf p. The pbuf is not deallocated.
> 
> >>udp_send() can't free it for you as it has no idea how you allocated
> it.
> >>For example, the pvMalloc() call above was used to create the payload
> area, but lwIP has no idea how to do the opposite of that to release the
> memory 
> >>you've used.
> >>
> 
> What I meant was the header buffer it creates, not my data allocation.

But you create the header buffer, so you have to free it.  Having
another look at the code I notice that in udp_send() it will add a
header buffer (and free it for you) if there is insufficient space in
the buffer you pass in, so if we didn't assert about the ROM pbuf in
pbuf_header() (i.e. your original problem) things would probably just
work.  If you'd like to file a bug to this effect (if possible quoting
this discussion) someone might get round to fixing this soon - I think
the best long term fix would be to change the bit in udp_send that trys
to do a pbuf_header() call to not try that if it's a ROM or REF pbuf.

> When I send the first packet I see that data->payload now has a pointer
> and data->len is now 44, overall length is (7*188)+44, I would have
> thought that this would be back to 0 and 7*188 after the send.

I think it will be like this before you send the first packet too - the
first pbuf you create with the call:

data = pbuf_alloc( PBUF_TRANSPORT, 0, PBUF_RAM);

will straightaway have a payload pointer and length.  What will have
changed is that the payload point will have moved within the pbuf's
buffer as it progressed through the network stack, which is why the
available length has changed.

> >>One other thing that concerns me about the above is that it suggests
> that you are assuming that by the time the udp_send() call returns,
> there will be no 
> >>further need to access the memory you passed in.
> >>Depending on your hardware, and the driver that sits underneath lwIP,
> this might not be the case.  lwIP has finished with it, but the driver
> might not have got 
> >>it onto the wire yet.  However, there's no visible way to find out
> when it is safe to free the memory for UDP.  For TCP we have the "sent"
> callback.  So not a 
> >>lot you can do about that, but worth being careful and making sure
> it's not a problem for you.
> >>
> >>Kieran
> 
> I am pretty sure that the data will be available as I said before the
> buffer is 512K and for this to wrap around before a packet is sent
> should not happen.

It was the pbuf created to hold the headers that I was concerned about,
rather than your circular buffer.

Kieran