lwIP - A Lightweight TCP/IP stack - Bugs: bug #65590, Windows: thread holder reset...
You are not allowed to post comments on this tracker with your current authentication level.
bug #65590: Windows: thread holder reset prematurely, breaking lock checks
Submitter: | Alexander Festini <afestini> | ||
Submitted: | Sun 14 Apr 2024 06:54:06 AM UTC | ||
Category: | Platform ports | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Planned Release: | None |
lwIP version: | git head |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
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.
No changes have been made to this item
Powered by Savane 3.13-bb6a.
Corresponding source code
The underlying mutex is recursive and judging from some logging, will have nested locks in some cases.
Setting the thread holder to 0 on every unlock without checking the number of lock calls results in incorrect asserts.
The line
lwip_core_lock_holder_thread_id = 0;
should only be executed when the last lock is released, either by keeping a counter to track locks/unlocks or (if possible) by getting that information from the mutex itself.