[GRASS5] site modules bug (?) - 1000 sites limit?

GRASS GRASS developer
1

On Fri, Jan 26, 2001 at 05:36:47PM +0000, Markus Neteler wrote:

Hi again,

it seems these days I am only bug-hunting...

While visiting various sites format to implement
multi-dimension support I found that

in various readsite[s].c following is defined:

int allocated=1000;

[...]
  (*xyz) = (Z *) G_malloc (allocated * sizeof (Z));
[...]

Am I right that this would cause problems with more
than 1000 sites?

But later there is some realloc statement. Mhhh...

A general improvement would be to remove the individual
readsite[s].c files and use the G_readsites_xyz() from
Eric to move this function to API.

Yea, I kind of slowed down updating/changing all those modules.
Generally they work, right? Some of these modules will read all the
data into memory, so really big sites list might cause memory problems.

If there's any that seem to have a pressing need for a change, let me
know. Otherwise, I don't really intend to do much. Seems this site
list format won't live much past 5.0 in it's current state, so at some
future date, *all* such modules will have to be revisted.

Currently, I'm trying to track down NVIZ memory leak in Keyframe
animation. My initial investigation points to the ogsf library, but I'm
not sure.

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

On Fri, Jan 26, 2001 at 08:26:05PM -0800, Eric G . Miller wrote:

On Fri, Jan 26, 2001 at 05:36:47PM +0000, Markus Neteler wrote:
> Hi again,
>
> it seems these days I am only bug-hunting...
>
> While visiting various sites format to implement
> multi-dimension support I found that
>
> in various readsite[s].c following is defined:
>
> int allocated=1000;
>
> [...]
> (*xyz) = (Z *) G_malloc (allocated * sizeof (Z));
> [...]
>
> Am I right that this would cause problems with more
> than 1000 sites?
>
> But later there is some realloc statement. Mhhh...
>
> A general improvement would be to remove the individual
> readsite[s].c files and use the G_readsites_xyz() from
> Eric to move this function to API.

Yea, I kind of slowed down updating/changing all those modules.
Generally they work, right?

Since a few days with multi-*dimensions* :slight_smile:
There was some ugly hacking in five of the modules not
using the info of G_site_describe(). Have fixed that
and added a parameter to select the decimals field (in case of
multi*attribute* lists.

Some of these modules will read all the
data into memory, really big sites list might cause memory problems.

There is another bug:

if you have an empty labels| field, the s.info seg.faults :frowning: Already
posted on RT.
Such a labels field is generated by r.to.sites and r3.to.sites.

If there's any that seem to have a pressing need for a change, let me
know. Otherwise, I don't really intend to do much. Seems this site
list format won't live much past 5.0 in it's current state, so at some
future date, *all* such modules will have to be revisted.

That's fine. Meet these modules later, generally they are o.k. now.

Currently, I'm trying to track down NVIZ memory leak in Keyframe
animation. My initial investigation points to the ogsf library, but I'm
not sure.

I think that Bob Covill already made a fix for that a few days ago?

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'