So you agree that it may be worse trying to fix those
mem allocation issues to get r.los to work on Win32?
Ben
Glynn Clements wrote:
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.
--
Benjamin Ducke
Senior Applications Support and Development Officer
Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.
Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
[EMAIL PROTECTED]
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document
Format). If you have difficulty opening them, please visit http://iso26300.info
for more information.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
