buglwIP - A Lightweight TCP/IP stack - Bugs: bug #21356, client thread freezes after...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #21356: client thread freezes after MEMP_TCPIP_MSG starvation

Submitted by:  Marc Chaland <chaland>
Submitted on:  Wed 17 Oct 2007 09:50:31 AM UTC  
 
Category: sockets/netconnSeverity: 3 - Normal
Item Group: Faulty BehaviourStatus: Duplicate
Privacy: PublicAssigned to: None
Open/Closed: ClosedPlanned Release: None
lwIP version: None

Wed 17 Oct 2007 08:41:59 PM UTC, comment #3:

>TCPIP msg is taken from the stack. I don't understand how another thread might asynchronously retrieve valid memory from this stack ? Isn't this fix dangerous ?


It's not asynchronsly, since the "netconn side" thread always wait that tcpip_thread end the action before return, so, this is not dangerous. Since the change was done there is several months, I think we can consider that as stable. There is in the CVS HEAD lot of change to fix several lot of problems with sequential api. Now, I think we can tell it's really more stable than 1.2.0. So, I suggest you to upgrade your port to HEAD code. You can find some informations here : http://lwip.scribblewiki.com/LwIP_version_1.3.0_release_notes

Note this particular point around your problem: "New MEMP_NUM_TCPIP_MSG_API and MEMP_NUM_TCPIP_MSG_INPKT replace older MEMP_NUM_TCPIP_MSG."

>As a consequence sys_mbox_post may fail.


lwIP sequential API is (and was) design on the fact that "sys_mbox_post" should never failed. So, you should change your sys_arch to avoid this case...

I close this record, but if you have some others questions, please, feel free to send it (if they are on HEAD code, perhaps "lwip-devel" mailing list is better than the bugtracker).

Frédéric Bernon <fbernon>
Project Member
Wed 17 Oct 2007 11:00:20 AM UTC, comment #2:

OK, I didn't check out all the sources from CVS as I cannot get it through my fw.

Into HEAD revision, TCPIP msg is taken from the stack. I don't understand how another thread might asynchronously retrieve valid memory from this stack ? Isn't this fix dangerous ?

I believe, memory should be allocated into tcpip_apimsg as into sys_mbox_post. As a consequence sys_mbox_post may fail.

Marc Chaland <chaland>
Wed 17 Oct 2007 10:27:49 AM UTC, comment #1:

This bug is already fixed in CVS HEAD, I propose to close it as "Invalid" or "Duplicate" (or "Done").

Frédéric Bernon <fbernon>
Project Member
Wed 17 Oct 2007 09:50:31 AM UTC, original submission:

When no more MEMP for TCPIP msg is available, client thread are stuck into mbox_fetch(conn->mbox) as tcpip thread doesn't receive the request.
I've made a patch: sys_mbox_post and tcpip_apimsg return error code when allocation fails and netconn_* functions manages this to avoid mbox_fetch on conn->mbox.

Marc Chaland <chaland>

 

Attached Files
file #14154:  lwip-1.2.0.patch added by chaland (6KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by fbernon (Posted a comment)
  • -unavailable- added by chaland (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 17 Oct 2007 08:41:59 PM UTCfbernonStatusNone=>Duplicate
      Open/ClosedOpen=>Closed
    Wed 17 Oct 2007 09:50:31 AM UTCchalandAttached File-=>Added lwip-1.2.0.patch, #14154

    Back to the top


    Powered by Savane 3.1-cleanup1