[PATCH] leak in init_valid_table

Martin Pool mbp at samba.org
Fri Feb 21 03:19:02 GMT 2003


util_unistr.c/init_valid_table in HEAD and 3.0 causes a 64k leak every
time the configuration is loaded if there is no valid.dat file
installed.  (The pointer to the malloc'd valid_table is clobbered by
the call to map_file.)

It looks like it is intended that the valid table be recreated on each
reload in case the dos codepage has changed.  Is that right?

The commit comment for 1.87 says that this should remove the need for
valid.dat.  Rather than fixing the leak I wonder if it would be better
to now just remove valid.dat support altogether?

If you don't want to do that, I think this patch will remove the leak.


--- util_unistr.c.~1.99.~	2003-02-21 14:05:33.000000000 +1100
+++ util_unistr.c	2003-02-21 14:14:20.000000000 +1100
@@ -105,27 +105,34 @@ static int check_dos_char(smb_ucs2_t c)
  **/
 void init_valid_table(void)
 {
-	static int initialised;
 	static int mapped_file;
 	int i;
 	const char *allowed = ".!#$%&'()_-@^`~";
+	uint8 *valid_file;
 
-	if (initialised && mapped_file) return;
-	initialised = 1;
+	if (mapped_file) {
+		/* Can't unmap files, so stick with what we have */
+		return;
+	}
 
-	valid_table = map_file(lib_path("valid.dat"), 0x10000);
-	if (valid_table) {
+	valid_file = map_file(lib_path("valid.dat"), 0x10000);
+	if (valid_file) {
+		valid_table = valid_file;
 		mapped_file = 1;
 		return;
 	}
 
-	/* Otherwise, using a dynamically loaded one. */
+	/* Otherwise, we're using a dynamically created valid_table.
+	 * It might need to be regenerated if the code page changed.
+	 * We know that we're not using a mapped file, so we can
+	 * free() the old one. */
 	if (valid_table) free(valid_table);
 
 	DEBUG(2,("creating default valid table\n"));
 	valid_table = malloc(0x10000);
-	for (i=0;i<128;i++) valid_table[i] = isalnum(i) || 
-				    strchr(allowed,i);
+	for (i=0;i<128;i++)
+		valid_table[i] = isalnum(i) || strchr(allowed,i);
+	
 	for (;i<0x10000;i++) {
 		smb_ucs2_t c;
 		SSVAL(&c, 0, i);



-- 
Martin 


More information about the samba-technical mailing list