cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
3,986 Views
Registered: ‎01-24-2010

xapp1026 sys_thread memory leaks

Jump to solution

In the lwip socket-mode example code provided with xapp1026, when a new socket connection is accepted via lwip_accept, a new thread is typically spawned with sys_thread_new with the socket descriptor passed as the thread's argument. Each of these spawned threads then performs the operations for that connection (i.e. serving a web page or running the rxperf test). Once complete, these threads typically self-terminate--that is, return to the operating system scheduler in presumeably a dead state. The xilkernel library automatically cleans up threads that self-terminate by freeing up the internal pthread resource. However, there doesn't appear to be anything in place to clean up the thread control structures allocated by sys_thread_new. In the sys_arch.c port file provided with the lwip library, only 100 sys_thread structures are statically defined and these are chosen in a linear search fashion via "sys_thread.tid==TID_FREE" by the sys_thread_new routine.

 

Is it a mistake to say that the xapp1026 web server example will cease to work properly once it has served 100 requests because there is nothing to clean up the sys_thread.tid fields (i.e. resetting them to TID_FREE as defined sys_arch.c)?

 

A little verification and/or clarification from a Xilinx engineer would be appreciated as this could be a rather large oversight in the provided library code.

 

The sys_thread_new function is also definitely not thread safe as access to the global sys_threads array is not protected (i.e. by a mutex). Its also unclear what the "thread safety" status is of the other functions in the sys_arch.c port file for lwip.

 

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
4,843 Views
Registered: ‎01-18-2008

If you look at the file contrib/ports/xilinx/sys_arch.c, you'll see the following function:

 

static void *                 

thread_start(void *arg)

{

        struct thread_start_param *tp = arg;

        tp->function(tp->arg);

        tp->thread->tid = TID_FREE;      /* Free up the thread structure */

        return NULL;  

}

 

The tp->function(), is really what calls the user level thread that was created with sys_thread_new. When this function returns, the next statement frees up the thread structure by setting it to TID_FREE.

 

Also, I have tested the webserver by letting it run for hours on end during which time I'm sure many thousands of threads were created and destroyed. And I haven't seen any issues after 100 threads. 

View solution in original post

0 Kudos
2 Replies
Highlighted
Xilinx Employee
Xilinx Employee
4,844 Views
Registered: ‎01-18-2008

If you look at the file contrib/ports/xilinx/sys_arch.c, you'll see the following function:

 

static void *                 

thread_start(void *arg)

{

        struct thread_start_param *tp = arg;

        tp->function(tp->arg);

        tp->thread->tid = TID_FREE;      /* Free up the thread structure */

        return NULL;  

}

 

The tp->function(), is really what calls the user level thread that was created with sys_thread_new. When this function returns, the next statement frees up the thread structure by setting it to TID_FREE.

 

Also, I have tested the webserver by letting it run for hours on end during which time I'm sure many thousands of threads were created and destroyed. And I haven't seen any issues after 100 threads. 

View solution in original post

0 Kudos
Highlighted
Observer
Observer
3,961 Views
Registered: ‎01-24-2010

You're right. I actually found that function myself not too long after I wrote that post. There should be no memory leak of lwip thread structures.

 

I'm still concerned about the lack of thread safety in the sys_arch functions. I have wrapped the call to sys_thread_new with another function that uses a pthread_mutex to synchronize access to lwip thread creation.

0 Kudos