Re: memory leaks from calls to opendir and fopen

Is anyone reporting these bugs to the glibc group, since they are really 
glibc bugs?  Just making sure...

-Corey

Saurabh Desai wrote:

>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)
>
>
>
>_______________________________________________
>pthreads-users mailing list
>[email protected]
>http://www-124.ibm.com/developerworks/oss/mailman/listinfo/pthreads-users
>  
>