buglwIP - 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: 

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.

Sylvain Rochet <gradator>
Group Member
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

Especially within the error callback (I guess there was the main problem). But also within received sometimes.

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.

By implementing the checks i found out that there is an ETH interrupt that is called. But i changed the application and now everything is called from the same main loop and is not interrupted by anything.

The problem is nothing changed. (It only got way slower).

The functions that where called from the Ethernet input interrupt where: pbuf_free, lwip_htons, netif->input(...), pbuf_header, pbuf_alloc.

So i guess these arent the problems ?

the tcp thread mutex locks arent even called.




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.

Please add support for LWIP_ASSERT_CORE_LOCKED (and LWIP_MARK_TCPIP_THREAD if necessary) before anything else.

(As a side note, tcp_recved() is usually called from the TCP recv callback and, as such, does not need locking).

Sylvain Rochet <gradator>
Group Member
Fri 17 Mar 2023 01:50:40 PM UTC, comment #2: 


comment #1:

> This is probably a threading issue, tcp_* API is not thread safe.
>
> Are you using threads ?
>
> Are you checking contexts using the LWIP_MARK_TCPIP_THREAD / LWIP_ASSERT_CORE_LOCKED feature ?
>
> Common pitfalls for reference: https://www.nongnu.org/lwip/2_0_x/pitfalls.html


We use a self written interface to LWIP. That ensures everything is called without beeing interrupted. I added the interfaces


    uint32_t tmp_Context = HItfIhandler::Get()->StartCriticalSection();
    tcp_recved(d->pcb, p->tot_len);
    HItfIhandler::Get()->EndCriticalSection(tmp_Context);

within these critical sections no other interrupts can be executed. And because we have only a single core there is no direct parallel access. I Checked it and there is no call to the library without guards. maybe this is not enough?

(file #54506)

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.

Are you using threads ?

Are you checking contexts using the LWIP_MARK_TCPIP_THREAD / LWIP_ASSERT_CORE_LOCKED feature ?

Common pitfalls for reference: https://www.nongnu.org/lwip/2_0_x/pitfalls.html

Sylvain Rochet <gradator>
Group Member
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.

This happens in file tcp_in.c at line 271.
prev->next = pcb->next;

the list can point directly to itself or over a few elements.
I attach my configuration. And a few screenshots of the environment at the error.

This happens always and is easily reproduceable.

Maximilian Mayr <mmay>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #54506:  networkInterface.cpp added by mmay (17KiB - text/plain)
file #54504:  wireshark.PNG added by mmay (76KiB - image/png - Additional info from wireshark 192.168.0.12 (Qt-App) and 192.168.0.10 (LWIP Device))
file #54505:  wireshark.txt added by mmay (3KiB - text/plain - Additional info from wireshark 192.168.0.12 (Qt-App) and 192.168.0.10 (LWIP Device))
file #54501:  lwipopts.h added by mmay (3KiB - text/plain)
file #54502:  Unbenannt.PNG added by mmay (7KiB - image/png)
file #54503:  Unbenannt1.PNG added by mmay (52KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gradator (Posted a comment)
  • -email is unavailable- added by mmay (Submitted the item)
  •  

    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 StatusNeed Info Invalid
        Open/ClosedOpen Closed
    2023-03-17 mmay Attached File- Added networkInterface.cpp, #54506
    2023-03-17 gradator StatusNone 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

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code