Re: [lwip-users] Simultaneous GET requests to HTTP Server

[Simeon Trifonov]

Simon, you gave me a great advice. I knew that I have to check my code 
and I made this many times unfortunately without result by now. But your 
words "check your code if there's something that could overwrite these 
fields..." focused my think in another direction. When I want to give a 
frame (received by the HW) to the stack, I reserve memory for a PBUF_REF 
buffer, then set the "payload" pointer to the frame (I want to avoid one 
more copy) and call the function input(). When the function input() 
returns, I release the memory for the buffer. Now I simply commented out 
the release of the memory and the device works without any problem even 
with 6 parallel GET request. All seems to work perfect, looking in the 
Wireshark logs. Of course it works until all the memory is consumed. I 
don't really know why this solved the problem, but probably I release 
the memory too early and the stack still use it, meantime the same 
memory is allocated again and used from another function. But now it 
comes the other question. When I have to release the memory for this 
buffer? How could I know when the stack has finished his work with it? 
Can you give an advice?

Simeon


On 21.6.2017 г. 13:52 ч., Simon Goldschmidt wrote:
> Simeon Trifonov wrote:
> > I' looking in the content of the corresponding pcb, especially the member 
> > "unacked". Here is what I see:
> > The variable "len" seems to be ok - 1460. The pointer "p" points the buffer with "len" 
> > set to 54 and "tot_len" set to 1514.
> > This seems to be correct too. The pointer "next" is valid (not null), so it 
> > must point the rest of the frame (1514 bytes).
> I don't want to include your screenshots again, so I'll try to do without.
> What you see is a segment of 1460 bytes of user data (unacked->len). Now that 
> segment has already been sent, so the pbufs contain
> headers (ETH, IPv4, TCP = 54 bytes). These are stored in an extra pbuf so the 
> whole frame is 1514 bytes long.
>
> In theory, the first pbuf of this segment is OK (len=54, tot_len=1514), but the 
> next should be len=tot_len=1460, so definitively,
> there is something wrong.
>
> At first sight of such problems, I always assume violation of lwIP's threading 
> requirements (don't call into the core code from
> more than one thread or from thread + interrupt). But this also could be 
> something completely different.
>
> What's strange is that the pbuf's type, ref and payload seem to be OK but the 
> len not. My best suggestion is try to check your code
> if there's something that could overwrite these fields...
>
> Simon
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users

--
Simeon Trifonov
Head of department "Development"

AMK Drives and Controls Ltd.
Bulgaria / Gabrovo

Phone:   +359 (0)66 819125
Fax:     +359 (0)66 819101
E-Mail:  address@hidden
Web:     www.amk-drives.bg