Re: memory leaks from calls to opendir and fopen

"Saurabh Desai" <[email protected]> Mon, 29 Jul 2002 12:06:32 -0500
Newsgroups gmane.linux.ngpt.user
Message-ID <[email protected]>

Yes, the fopen() still uses memory with previous fix and the following
patch in ngpt
fixes that problem, I had missed it earlier in pthread_mutex_unlock() (in
pthread.c).
Apply this on top of previous ngpt-2.0.0 patch. About the statvfs(), I
don't think it uses
pthread mutexes. However, there are some cases from glibc, where it calls
libc_lock_lock(),
still create problems with memory usage, because of no corresponding
mutex_destroy calls.
I believe there are not many such cases.  We will investigate that further
in ngpt and let you
know as soon as we find anything.

Thanks,
Saurabh

=====================================================================
diff -Naur ngpt-2.0.0/pthread.c ngpt-2.0.0-destroy/pthread.c
--- ngpt-2.0.0/pthread.c        Mon Jul 29 09:49:06 2002
+++ ngpt-2.0.0-destroy/pthread.c        Mon Jul 29 09:12:38 2002
@@ -1068,10 +1068,8 @@

     if (mutex == NULL)
         return EINVAL;
-    if (*mutex == PTHREAD_MUTEX_INITIALIZER || *mutex ==
LT_MUTEX_INITIALIZER) {
-        if (pthread_mutex_init(mutex, NULL) != OK)
-            return EINVAL;
-    }
+    if (*mutex == PTHREAD_MUTEX_INITIALIZER || *mutex ==
LT_MUTEX_INITIALIZER)
+       return EINVAL;
     if (((pth_mutex_t *)*mutex)->mx_state & PTH_MUTEX_INTERNAL_LOCKED) {
        _pth_release_lock(&(((pth_mutex_t *)*mutex)->mx_lock), 0);
        return OK;





Nathan Falk/Poughkeepsie/IBM@[email protected] on
07/25/2002 03:47:37 PM

Sent by:    [email protected]


To:    Saurabh Desai/Austin/IBM@IBMUS
cc:    [email protected]
Subject:    Re: [pthreads-users] memory leaks from calls to opendir and
       fopen



The patch solves the problem of opendir() but fopen() still grows the
program.  statvfs(), also, but that doesn't have a complementary call like
closedir() or fclose(), so I'm not sure what's going wrong there.  The test
program I previously provided can be easily modified to demonstrate these
remaining leaks.

Regards,

Nate Falk
RS/6000 SP Workload Management/LoadLeveler
845-433-8162 (T/L: 293-8162)