[lwip-devel] Oddity in netconn_new_with_proto_and_callback

[Taranowski, Thomas \(SWCOE\)]

Can someone please explain to me why the following excerpt isn’t a bug?  My running commentary is prefixed with TT:

 

Excerpt from function ‘netconn_new_with_proto_and_callback’, which is run in the user thread context.

 

… some code …

TT: Ok, here we allocate space for the msg.  So far so good.

if((msg = memp_malloc(MEMP_API_MSG)) == NULL) {

LWIP_DEBUGF(NETCONN_DEBUG, ("netconn_new_with_proto_and_callback(): Failed memp_malloc(MEMP_API_MSG)"));

            memp_free(MEMP_NETCONN, conn);

            return NULL;

      }

… some code …

 

msg->type = API_MSG_NEWCONN;

msg->msg.msg.bc.port = proto; /* misusing the port field */

msg->msg.conn = conn;

TT: Here the msg is posted to the tcpip mailbox, with type TCPIP_MSG_API.  When the lwIP tcpip_thread executes next, it will handle the msg by calling api_msg_input.

api_msg_post(msg); 

TT: I have no idea what this does, but it looks important. I’m assuming it’s making sure some timeout handlers have a chance to run.

sys_mbox_fetch(conn->mbox, NULL);

TT: AHHH. We’re freeing the msg NOW?  How do we now that the lwIP core tcpip_thread has processed this msg?  It probably hasn’t, and could be accessing the already freed msg, but no one would really notice, because msg will not be overwritten until the memp_malloc wraps around the pool, and reallocates this particular memp memory area. 

memp_free(MEMP_API_MSG, msg);

 

if ( conn->err != ERR_OK ) {

  LWIP_DEBUGF(NETCONN_DEBUG, ("netconn_new_with_proto_and_callback(): netconn failure, err=%d"));

  memp_free(MEMP_NETCONN, conn);

  return NULL;

}

 

      return conn;

}

 

 

Thanks in advance for helping my pea brain grow.

-Tom