glob memory leak

[Andreas Jaeger <aj at suse dot de>]

Hi libc testers and developers,

is anybody interested in debugging glob (sysdeps/generic/glob.c)?
Salvador Castromil Martinez reported a memory leak in glob.  With
mtrace I was able to get the following information (for glibc 2.1.91):

Memory not freed:
-----------------
   Address     Size     Caller
0x080a06d0     0x1f  at /usr/src/cvs/libc/posix/../sysdeps/generic/glob.c:1152
0x080a06f8     0x1f  at /usr/src/cvs/libc/posix/../sysdeps/generic/glob.c:1152
0x080a0740     0x1f  at /usr/src/cvs/libc/posix/../sysdeps/generic/glob.c:1152
0x080a0770     0x1f  at /usr/src/cvs/libc/posix/../sysdeps/generic/glob.c:1152
0x080a0798     0x1f  at /usr/src/cvs/libc/posix/../sysdeps/generic/glob.c:1152
0x080a07c0     0x1f  at /usr/src/cvs/libc/posix/../sysdeps/generic/glob.c:1152
[..]
0x080a09f0     0x1f  at /usr/src/cvs/libc/posix/../sysdeps/generic/glob.c:1152
0x080a0a18     0x28  at /usr/src/cvs/libc/posix/../sysdeps/generic/glob.c:1389
0x080a0a48     0x1f  at /usr/src/cvs/libc/posix/../sysdeps/generic/glob.c:1152

Andreas

Subject: Topics

Topics:
   libc/1782: [50 character or so descriptive subject here (for reference)]

---

• To: bugs at gnu dot org
• Subject: libc/1782: [50 character or so descriptive subject here (for reference)]
• From: Salvador Castromil Martinez <castrom at attglobal dot net>
• Date: Tue, 20 Jun 2000 16:29:44 +0200

>Number:         1782
>Category:       libc
>Synopsis:       [50 character or so descriptive subject here (for reference)]
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    libc-gnats
>State:          open
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Tue Jun 20 10:30:02 EDT 2000
>Last-Modified:
>Originator:     Salvador Castromil Martinez
>Organization:
 
>Release:        libc-2.1.2
>Environment:
	
Host type: i386-redhat-linux-gnu
System: Linux caponata.peaje.sice.es 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown
Architecture: i686

Addons: crypt glibc-compat linuxthreads
Build CFLAGS: -O3 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g
Build CC: egcs
Compiler version: egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
Kernel headers: 2.2.12-20
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: yes
Build omitfp: no
Build bounded: no
Build static-nss: no
Stdio: libio

>Description:
	

	The supposed bug came up when I have used the function 
	"glob" with wild-chars to find files in a relative big 
	directory structure. The problem is about memory leaks. 

>How-To-Repeat:
	

	I send you a list of the directory tree that I have used and the 
	source code of the simple program that generates that memory leak. 

	Directory tree:
	
	/tmp/imagenes
	/tmp/imagenes/001
	/tmp/imagenes/001/201
	/tmp/imagenes/001/201/20000617
	/tmp/imagenes/001/201/20000619
	/tmp/imagenes/001/201/20000620
	/tmp/imagenes/001/Envio01
	/tmp/imagenes/001/202
	/tmp/imagenes/001/202/20000617
	/tmp/imagenes/001/202/20000619
	/tmp/imagenes/001/202/20000620
	/tmp/imagenes/001/203
	/tmp/imagenes/001/203/20000617
	/tmp/imagenes/001/203/20000619
	/tmp/imagenes/001/203/20000620
	/tmp/imagenes/001/Envio02
	/tmp/imagenes/001/Envio03
	/tmp/imagenes/001/Error

	Sample program source:
	
#include	<stdlib.h>
#include	<time.h>
#include	<glob.h>

/*#define MYFREE	1*/

int main(int argc, char *argv[])
{
	struct timespec			xtimespec00, xtimespec01;
	glob_t				xglob_t01;
#ifdef	MYFREE
	int 				ecContI;
#endif

	xtimespec00.tv_sec = 0;
	xtimespec00.tv_nsec = 50000000;

	while (1)
	{
		if (glob ("/tmp/imagenes/???/???/????????/ft*.jpg", 0, 
				NULL, &xglob_t01)==GLOB_NOMATCH)
			printf ("Empty Glob.\n");
		else
			printf ("Glob with %d files.\n", 
					xglob_t01.gl_pathc);

#ifndef MYFREE
		globfree(&xglob_t01);
#else
		for (ecContI = 0; ecContI < xglob_t01.gl_pathc; ecContI++)
		{
			free (xglob_t01.gl_pathv+ecContI);
		}
		free (xglob_t01.gl_pathv);
#endif

		nanosleep (&xtimespec00, &xtimespec01);
	}

	return 0;
}
		
>Fix:
	

	I have tried to free the glob_t structure by myself (as you can see in
	the program) but the memory leak persist. 


	Thanks you,

		Salvador Castromil Martínez 
		e-mail <castrom@attglobal.net>
>Audit-Trail:
>Unformatted:

---

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de