[physfs] Possible mem corruption in 2.0.2 or just my bad?

Christian zicodxx at yahoo.de
Thu Jun 30 06:43:30 EDT 2011


Hey folks,

Yesterday I had an update of Valgrind (to Version 3.6.1) and after that my 
program began to report issues with PhysFS - specifically in 
PHYSFS_enumerateFilesCallback.

I am using an example from the documentation to list the Search Path contents:

void PHYSFSX_listSearchPathContent()
{
	char **i, **list;

	con_printf(CON_DEBUG, "PHYSFS: Listing contents of Search Path.\n");
	list = PHYSFS_getSearchPath();
	for (i = list; *i != NULL; i++)
		con_printf(CON_DEBUG, "PHYSFS: [%s] is in the Search Sath.\n", *i);
	PHYSFS_freeList(list);

	list = PHYSFS_enumerateFiles("");
	for (i = list; *i != NULL; i++)
		con_printf(CON_DEBUG, "PHYSFS: * We've got [%s].\n", *i);
	PHYSFS_freeList(list);
	
	con_printf(CON_DEBUG, "\n");
}

here Valgrind starts to complain:
==18794== Source and destination overlap in memcpy(0x9ad090b, 0x9ad090a, 9)
==18794==    at 0x4C27B46: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-
amd64-linux.so)
==18794==    by 0x5D759C4: ??? (in /lib/libc-2.14.so)
==18794==    by 0x5D75386: readdir (in /lib/libc-2.14.so)
==18794==    by 0x4E36977: ??? (in /usr/lib/libphysfs.so.2.0.2)
==18794==    by 0x4E37AB9: ??? (in /usr/lib/libphysfs.so.2.0.2)
==18794==    by 0x4E33D67: PHYSFS_enumerateFilesCallback (in 
/usr/lib/libphysfs.so.2.0.2)
==18794==    by 0x4E33DF8: PHYSFS_enumerateFiles (in 
/usr/lib/libphysfs.so.2.0.2)
==18794==    by 0x50E3DA: PHYSFSX_listSearchPathContent (physfsx.c:220)
==18794==    by 0x489D7F: main (inferno.c:334)

So I am unsure if this is a PhysFS bug or if I am just using these calls 
wrong. any ideas?

Best regards,
Christian


More information about the physfs mailing list