[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