lwIP - A Lightweight TCP/IP stack - Bugs: bug #27377, "op_completed" semaphore...
You are not allowed to post comments on this tracker with your current authentication level.
bug #27377: "op_completed" semaphore mechanism crash error
Submitter: | hanhui <hanhui03> | ||
Submitted: | Fri 04 Sep 2009 02:38:06 AM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Crash Error | Status: | Wont Fix |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | CVS Head |
Mon 05 Oct 2009 08:00:18 PM UTC, comment #5: |
Simon Goldschmidt <goldsimon> |
Fri 04 Sep 2009 07:44:31 AM UTC, comment #4: There is several posts about the multithreadinng question. You could find these previous chats in bugs/tasks sections.
|
Frédéric Bernon <fbernon> |
Fri 04 Sep 2009 07:25:27 AM UTC, comment #3: I recommend a solution: all thread which will call socket, has it's own synchronic semaphore. and tcpip thread use this semaphore synchronic user thread.
|
hanhui <hanhui03> |
Fri 04 Sep 2009 07:22:08 AM UTC, comment #2: Hi,
|
Frédéric Bernon <fbernon> |
Fri 04 Sep 2009 07:08:34 AM UTC, comment #1: another BUG found: user thread and tcpip thread synchronization mechanism.
|
hanhui <hanhui03> |
Fri 04 Sep 2009 02:38:06 AM UTC, original submission:
lwip application layer use tcpip_apimsg()[or other similar functions] send a message to tcpip thread. for example: netconn_XXX() usually call tcpip_apimsg() to execute do_XXX() function.
|
hanhui <hanhui03> |
No files currently attached
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 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2009-10-05 | goldsimon | Open/Closed | Open | Closed | |
Status | None | Wont Fix | |||
Assigned to | None | goldsimon |
Powered by Savane 3.13-02a9.
Corresponding source code
I guess what hanhui initially posted is a (potential) bug report that op_completed might be posted by err_tcp and not checked by another task afterwards.
However, since op_completed is only posted in states NETCONN_WRITE, NETCONN_CLOSE and NETCONN_CONNECT, there is another task waiting and the errors he saw are (supposedly) only related to the fact the he used multiple threads on one netconn, which is not supported (and will not be unless that API is redesigned).