Hi Jorge, Jorge Arellano Cid writes:
Hi,
Is anyone here savvy on using dynamic memory allocation in pthreads?
The problem: while hunting a bug that showed after the large parser orthogonalization patch, it was finally found between dillo and the file dpi server; it was a critical race. I recoded the file server to use pthreads and it went away, but...
... the new file server started to increase dramatically its virtual size.
The threads are allocating memory and freeing it with the usual g_malloc/g_free pair, but it seems like these blocks remain allocated even after the thread is finished.
I don't have time to really look at this, but are you using g_thread_init(), gdk_threads_init(), gdk_threads_enter(), gdk_threads_leave() and company? Here is some info: http://www.gtk.org/faq/#AEN482 I wouldn't be surprised if GLib gets confused without calling g_thread_init(). Specifically, if I remember correctly, the locking of GLibc's internal variables is only actually done when g_thread_init() is executed. This _might_ explain your problem... but it might be a long shot, since a race condition is needed to activate the possible problem. If you're sure, however, that g_malloc and g_free are the source for your memory leak, that the problem is something else (in GLib 1.2, at least, g_malloc and g_free map almost directly to malloc() and free(), which are thread-safe). The only big caveat of malloc/free is that they are not signal-safe, i.e., you shouldn't use them (along with a hoard of other things in libc and systems calls, etc) in signal handlers.
This may be the same root for the reload memory leak pointed somtime ago, do you remember? The IO engine uses a pthread to make the request.
It seems that there's an API to use "thread specific data" or TSD by using pthread_key_create() and akin functions. Does anyone know if this is the only way, or an URL of a good tutorial on how to do this?
Thread specific data is a solution, but I'd recommend avoiding it as much as possible. There should be a way to figure out what is going on with your memory leaks... Hope this helps, -- Livio B. Soares