Hi,
as those of you who followed the discussions on r.cva/r.los on the Win32
platform lately may remember that there is a problem in the r.los code
that leads to segfaults on Win32 (mingw/msys).
The general problem is that Linux has a pretty relaxed mem management:
if memory is free'd and then accessed, it does not create a fatal
conditition as long as that mem region was not changed in the meantime.
Thus, programmers get away with a lot of unclean memory handling.
On Win32, the mem manager seems to be more strict and this leads to
segfaults in the same situation.
Since there is a lot of demand for visibility analysis with GRASS, I
decided to give r.los some testing with GDB and valgrind.
This is what I could track the problem down to:
pts_elim.c:
line 103: in some freakish circumstance, CHECKED_PT is set to point to a
a region that was previously free'd. The next attempt at accessing its
data fields will crash the program.
The free'ing is done by delete.c, lines 39 and 47.
Obviously, there is a missing condition here, so that a point gets
deleted from the processing list prematurely.
If I comment out both G_free() statements, r.los finishes its job!
However, this causes a nice big mem leak, of course (sth. like 12 bytes
per cell within the considered radius) ...
At this point, my brain gets fried, because I do not understand the
logics behind r.los point data handling, how it builds the list of
points to process and how it deletes them.
If someone could figure this one out, or at least supply me with further
hints, r.los and thus r.cva will be able to run on Win32, allowing us to
include both in the next GRASS stable version. I am sure lots of people
would appreciate it!
Best,
Benjamin
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg