[GRASS5] G3D code question

[Soeren Gebbert]

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.