lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-devel] Oddity in netconn_new_with_proto_and_callback


From: Goldschmidt Simon
Subject: RE: [lwip-devel] Oddity in netconn_new_with_proto_and_callback
Date: Wed, 28 Feb 2007 09:26:00 +0100

Hi Thomas,
 
By calling api_msg_post() with a msg of type API_MSG_NEWCONN, do_newconn() in api_msg.c will be called, which will post to the connection's mbox when finished. Thus, the calling thread uses sys_moox_fetch() to wait for the tcpip_thread to finish the request. No access to already freed memory!
 
Simon


From: address@hidden [mailto:address@hidden On Behalf Of Taranowski, Thomas (SWCOE)
Sent: Wednesday, February 28, 2007 5:22 AM
To: address@hidden
Subject: [lwip-devel] Oddity in netconn_new_with_proto_and_callback

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]