Hi all,
i have some questions about the G3D lib code.
Im implementing some g3d modules on a Fedora Core 3 AMD Linux machine with grass6.1-cvs, and i detected some strange behaviour of my modules. So i checked the code and used valgrind to detect memoryleaks and stuff.
First question:
i detected a memory leak in the g3d lib, some output from /usr/local/bin/valgrind --tool=memchec -v:
start
==28561== at 0x1B909AD5: cache_queue_enqueue (cache.c:264)
==28561== by 0x1B909C45: cache_queue_preppend (cache.c:329)
==28561== by 0x1B90A031: cache_remove_elt (cache.c:506)
==28561== by 0x1B90A0F0: G3d_cache_flush (cache.c:540)
==28561== by 0x1B90A1FF: G3d_cache_flush_all (cache.c:580)
==28561== by 0x1B90EE33: G3d_flushAllTiles (g3dcache.c:369)
==28561== by 0x1B90F8CF: G3d_closeCellNew (g3dclose.c:58)
==28561== by 0x1B90FB0C: G3d_closeCell (g3dclose.c:152)
==28561== by 0x8049780: main (main.c:328)
==28561== Address 0x1BD7E057 is 1 bytes before a block of size 304 alloc'd
==28561== at 0x1B90088D: malloc (vg_replace_malloc.c:149)
==28561== by 0x1B90E38A: G3d_malloc (g3dalloc.c:33)
==28561== by 0x1B909789: G3d_cache_new (cache.c:150)
==28561== by 0x1B90EA81: initCacheWrite (g3dcache.c:225)
==28561== by 0x1B90EB33: G3d_initCache (g3dcache.c:257)
==28561== by 0x1B9188AF: G3d_fillHeader (header.c:457)
==28561== by 0x1B9145CB: G3d_openCellNew (g3dopen.c:317)
==28561== by 0x8049660: main (main.c:288)
end
grass6/lib/g3d/cache.c:329 :
"cache_queue_enqueue (c, -1, index);"
grass6/lib/g3d/cache.c:264 :
"if (IS_NOT_IN_QUEUE_ELT (left))"
left is -1 and the macro checks an array:
"(c->locks[elt] == 1)"
left == elt
Is this a magic trick?
"c->locks[-1] == 1" ?
Im not completly sure, but addressing an array with -1 is not usual and
may result in a segfault?
Can anybody give me a hint, or help if this is correct?
This behaviour also appears with r3.mapcalc.
Second question:
I detected a memory leak in grass6/lib/g3d/g3dopen.c. output from
/usr/local/bin/valgrind --tool=memcheck -v r3.out.ascii ... :
start
==13111== Syscall param read(buf) points to unaddressable byte(s)
==13111== at 0x1BAD7253: __read_nocancel (in /lib/tls/libc-2.3.5.so)
==13111== by 0x1B91404A: G3d_openCellOld (g3dopen.c:162)
==13111== by 0x804931C: main (main.c:278)
==13111== Address 0x1BB50C33 is 0 bytes after a block of size 3 alloc'd
==13111== at 0x1B90088D: malloc (vg_replace_malloc.c:149)
==13111== by 0x1B90E38A: G3d_malloc (g3dalloc.c:33)
==13111== by 0x1B914000: G3d_openCellOld (g3dopen.c:155)
==13111== by 0x804931C: main (main.c:278)
end
grass6/lib/g3d/g3dopen.c:155 :
"ltmp = G3d_malloc (map->indexNbytesUsed);"
grass6/lib/g3d/g3dopen.c:162 :
"if (read (map->data_fd, ltmp, map->indexLongNbytes) !="
read() puts map->indexLongNbytes Bytes in ltmp but map->indexNbytesUsed are allocated. Is map->indexNbytesUsed always bigger than map->indexLongNbytes? I dont know, so i changed this and the memory leak disapeared. But i dont know if i this is ok, because i dont know anything about the lib.
Any hints or help are welcome!
Here is the diff of my changes
Index: g3dopen.c
RCS file: /home/grass/grassrepository/grass6/lib/g3d/g3dopen.c,v
retrieving revision 2.1
diff -r2.1 g3dopen.c
155c155,156
< ltmp = G3d_malloc (map->indexNbytesUsed);
---
/*ltmp = G3d_malloc (map->indexNbytesUsed);*/
ltmp = G3d_malloc (map->indexLongNbytes); /*Soeren Gebbert 02.09.2005*/
Thanks and
Best regards
Soeren
btw.:
there are tons of uninitialised values in the g3d lib.