buglwIP - A Lightweight TCP/IP stack - Bugs: bug #20791, conn->recvmbox might be deleted...

 
 

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

bug #20791: conn->recvmbox might be deleted twice in netconn_delete() and netconn_recv

Submitter:  Howell ZHU <howellzhu>
Submitted:  Wed 15 Aug 2007 04:32:52 PM UTC
   
 
Category:  TCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None
lwIP version:  None

Jump to the original submission

Wed 22 Aug 2007 11:40:58 AM UTC, comment #7: 

So, it's not something which will be fixed for the moment...

This is something to document in http://lwip.scribblewiki.com/LwIP_and_multithreading

Frédéric Bernon <fbernon>
Group Member
Wed 22 Aug 2007 06:14:13 AM UTC, comment #6: 

no, go ahead.

Simon Goldschmidt <goldsimon>
Group administrator
Tue 21 Aug 2007 11:43:40 PM UTC, comment #5: 

Since we have already define in others tasks (see coment#2) that this kind of multithread issue would/is not be supported by lwip, I propose to close it as "invalid". No objects?

Frédéric Bernon <fbernon>
Group Member
Thu 16 Aug 2007 08:22:09 AM UTC, comment #4: 

First of all, since this part of the code has changed in current CVS HEAD (there is no sys_mbox_free in netconn_recv, and we have introduce LWIP_TCPIP_CORE_LOCKING option to avoid some deadlocking problems with the "mbox" way to communicate between the application task and the tcpip_thread), you should test it (like Jonathan say in comment #1, it's not a waste of time). If you do it, look the CHANGELOG file to see the differences, and perhaps take a look at "http://lwip.scribblewiki.com/LwIP_version_1.3.0_release_notes", even if it's not complete...

Frédéric Bernon <fbernon>
Group Member
Thu 16 Aug 2007 03:25:29 AM UTC, comment #3: 

Hi Jonathan and Frédéric,
Thank you for the comments and reference you provide!

I think it is a very common method in full-duplex communication application that one thread is blocked on calling recv and another used to send or close the connection according to local upper request.

Thus if we want to close the connection locally without invoking netconn_delete in other thread, there is no chance to unblock recv thread except for peer's disconnection ACK. However, in some bad situations, the peer's disconnection ACK might be lost.
So I think such operation MUST be processed in multi threads.

Based on the past discussion, I think this might be a better solution:
In function netconn_close, we signal recv thread that the connection is closed by sending a NULL message to recvmbox. Thus the recv thread will be unblocked and detect the disconnection. In following steps, recv thead will drain the recvmbox and call netconn_delete. Thus the multi-thread operation is avoided and netconn_recv is unblocked (so we can gracefully close the connection locally).


How about your opinions?
I'm not very familiar with this project. So I want to discuss it with you carefully:)

Howell ZHU <howellzhu>
Wed 15 Aug 2007 09:30:33 PM UTC, comment #2: 

More, lwIP is not safe-thread on one socket: you should not call with a Task A netconn_delete, in the same time a Task B is "blocked" on a netconn_recv. In a general way, you should not use two "application" tasks on a same socket/netconn... You can find some informations/talks on :

https://savannah.nongnu.org/task/?6683
https://savannah.nongnu.org/patch/?5960

Frédéric Bernon <fbernon>
Group Member
Wed 15 Aug 2007 04:49:47 PM UTC, comment #1: 

Hi Howell,

Thanks for the report. I believe this has already been fixed in lwIP CVS. Would you care to give it a try?

Note that there have been quite a few changes affecting ports though, so bringing your port over to match what is in CVS will take a little work. But it will become the basis of the lwIP 1.3.0 release which hopefully won't be too long away, so it won't be wasted.

Jonathan Larmour <jifl>
Group Member
Wed 15 Aug 2007 04:32:52 PM UTC, original submission:  

Assuming A task invoked netconn_delete(), while B task was pending on netconn_recv().
Firstly A task will attempt to delete the conn->recvmbox:
<quote>
  /* Drain the recvmbox. */
  if (conn->recvmbox != SYS_MBOX_NULL) {
    while (sys_arch_mbox_fetch(conn->recvmbox, &mem, 1) != SYS_ARCH_TIMEOUT) {
      if (conn->type == NETCONN_TCP) {
        if(mem != NULL)
          pbuf_free((struct pbuf *)mem);
      } else {
        netbuf_delete((struct netbuf *)mem);
      }
    }
    sys_mbox_free(conn->recvmbox); <<<-------HERE!!!
    conn->recvmbox = SYS_MBOX_NULL;
  }
</quote>
Then B task might be resumed and fetch NULL from the recvmbox. And it will delete the recvmbox too (in function netconn_recv())!!!
<quote>
    /* If we are closed, we indicate that we no longer wish to receive
       data by setting conn->recvmbox to SYS_MBOX_NULL. */
    if (p == NULL) {
      memp_free(MEMP_NETBUF, buf);
      sys_mbox_free(conn->recvmbox); <<<--------DELETE AGAIN!!!
      conn->recvmbox = SYS_MBOX_NULL;
      return NULL;
    }
</quote>
Thus the mbox might be delete twice and cause a critical error.

Howe about my suggestion?
DO NOT delete the recvmbox in fucntion netconn_recv(). Because netconn_delete() will delete and drain it.

Waiting for your opinions!

Howell ZHU <howellzhu>

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by jifl (Posted a comment)
  • -email is unavailable- added by howellzhu (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-08-22 fbernon StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code