lwIP - A Lightweight TCP/IP stack - Bugs: bug #63938, On apprupt tcp interrupten the...
You are not allowed to post comments on this tracker with your current authentication level.
bug #63938: On apprupt tcp interrupten the pcb->next list points to itself
Submitter: | Maximilian Mayr <mmay> | ||
Submitted: | Fri 17 Mar 2023 01:28:41 PM UTC | ||
Category: | IPv4 | Severity: | 3 - Normal |
Item Group: | Crash Error | Status: | Invalid |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | 2.1.3 |
Jump to the original submission
Thu 30 Mar 2023 06:18:52 PM UTC, comment #6: |
Sylvain Rochet <gradator> |
Wed 29 Mar 2023 09:31:10 AM UTC, comment #5: I gues we found the problem. We called tcp_abort() within some of the callbacks and dont return ERR_ABRT. Which can cause memory leaks. https://www.nongnu.org/lwip/2_0_x/group__tcp__raw.html#ga468c2260ddb01582e966ddcf3c25ce61
|
Maximilian Mayr <mmay> |
Mon 27 Mar 2023 01:10:39 PM UTC, comment #4: Soory for letting you wait. It took me some time to check how lwip wants me to implement the LWIP_MARK_TCPIP_THREAD / LWIP_ASSERT_CORE_LOCKED and make it work. I also went back to D.A.V.E (An IDE that creates low level code for our arm based CPU XMC4700) and checked all settings but everything is correct.
|
Maximilian Mayr <mmay> |
Tue 21 Mar 2023 03:34:36 PM UTC, comment #3: Linked list corruption is the most common issue of contexts clash.
|
Sylvain Rochet <gradator> |
Fri 17 Mar 2023 01:50:40 PM UTC, comment #2:
|
Maximilian Mayr <mmay> |
Fri 17 Mar 2023 01:37:47 PM UTC, comment #1: This is probably a threading issue, tcp_* API is not thread safe.
|
Sylvain Rochet <gradator> |
Fri 17 Mar 2023 01:28:41 PM UTC, original submission:
When stopping an active ipv4/tcp connection via "hard stop" in our case Qt-Application debelopment crash. The pcb list can be corrupt when the next connection starts.
|
Maximilian Mayr <mmay> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 9 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2023-03-30 | gradator | Status | Need Info | Invalid | |
Open/Closed | Open | Closed | |||
2023-03-17 | mmay | Attached File | - | Added networkInterface.cpp, #54506 | |
2023-03-17 | gradator | Status | None | Need Info | |
2023-03-17 | mmay | Attached File | - | Added wireshark.PNG, #54504 | |
Attached File | - | Added wireshark.txt, #54505 | |||
2023-03-17 | mmay | Attached File | - | Added lwipopts.h, #54501 | |
Attached File | - | Added Unbenannt.PNG, #54502 | |||
Attached File | - | Added Unbenannt1.PNG, #54503 |
Powered by Savane 3.13-caa5.
Corresponding source code
You guessed wrong, calling netif->input() from interrupt context is obviously a serious mistake unless lwIP runs entirely in interrupt context.
For pbuf allocation from other contexts, see SYS_LIGHTWEIGHT_PROT. For pbuf de-allocation from other contexts (far less common than allocation though), see LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT.
Of course mutex locks are not called because you do not use an OS, the contrary would be quite surprising.
And indeed, not returning ERR_ABRT when tcp_abort() was called is a documented API misuse.