[GRASS-dev] R: [GRASS-windows] WinGRASS: Test Build on Vista

[Glynn Clements]

Benjamin Ducke wrote:

> Actually, r.los seems to have faulty mem management on all platforms.
> If I valgrind the module, I get:
> 
> ==20182==    at 0x804AB15: hidden_point_elimination (pts_elim.c:105)
> ==20182==    by 0x8049D74: main (main.c:303)
> ==20182==  Address 0x4691CB8 is 24 bytes inside a block of size 32 free'd
> ==20182==    at 0x402237F: free (vg_replace_malloc.c:233)
> ==20182==    by 0x403767C: G_free (alloc.c:126)
> ==20182==    by 0x8049673: delete (delete.c:39)
> ==20182==    by 0x804AB14: hidden_point_elimination (pts_elim.c:189)
> ==20182==    by 0x8049D74: main (main.c:303)
>   100%
> ==20182==
> ==20182== Conditional jump or move depends on uninitialised value(s)
> ==20182==    at 0x40A6CB2: (within /usr/lib/libz.so.1.2.3.3)
> ==20182==    by 0x40A7E5F: deflate (in /usr/lib/libz.so.1.2.3.3)
> ==20182==    by 0x40463A7: G_zlib_compress (flate.c:359)
> ==20182==    by 0x4046551: G_zlib_write (flate.c:224)
> ==20182==    by 0x405D54F: G__write_data_compressed (put_row.c:337)
> ==20182==    by 0x405DE89: put_raster_row (put_row.c:477)
> ==20182==    by 0x804A007: main (main.c:351)
> ==20182==
> 
> ... and a dozen more like that. Not a good sign really.
> 
> My guess is that whether r.los crashes or not is simply due to
> how relaxed the OS's memory allocation scheme is. Some systems
> are more forgiving for the sake of better performance. I guess
> that XP is more on the strict side and thus kills the module,
> while Linux and Vista let you get away with it.

It's more likely to be plain luck rather than any specific design
factor.

Whether or not you get away with continuing to use freed memory
depends upon whether that memory gets re-used. In turn, that depends
upon which other allocations occur.

-- 
Glynn Clements <glynn at gclements.plus.com>