Sorry, forgot to add I'm running NO_SYS = 1. slc
On 10/25/2022 8:46 PM, Stephen Cowell wrote:
My product is a modbus TCPIP board, using the Atmel SAM4E16E based off
of the SAM4E-EK. It is using LWiP 1.4.1 with pbuf.c and pbuf.h from
version 2.1.3. I know... cringe... but I did this recently, during
troubleshooting... helped some, see below.
I'm banging it real hard using DaqFactory to create two simultaneous
threads sending modbus requests to the same port/address. As I do
this I can see the pbuf_pool pbufs being created higher and higher up
the pool... I can debug on the pbuf deallocation and see that the
->next is NULL, so there is no connection to the rest of the chain.
If I let this go on for long enough the processor will hard fault.
I had this behavior happen very quickly before I moved from LWiP mem
management to GNU C library malloc()... now it takes a long time to
die. Also, after I spliced in the pbuf code from the latest-greatest
it did seem to become more robust... but I can still watch the
allocated pbufs climb up the pool, leaving behind orphan pbufs as a
memory leak.
I guess my main question is... should LWiP be able to survive this
kind of abuse? I'm able to hit it with requests about every two
milliseconds... and it takes about an hour before it runs out of
memory. Would I notice any improvement by completing the port to
2.1.3 (a significant effort)? Is LWiP tested in this way? It's worth
noting that DaqFactory is glitching the inputs it receives
sometimes... but Wireshark shows them to be rock solid (when there's
not a timeout or port locked complaint). Am I abusing it too hard?
Thanks for your time... Steve.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
