[GRASS-dev] [bug #5264] (grass) v.digit - G_malloc out of memory error

GRASS GIS GRASS GIS developer
1

neteler@itc.it wrote (Sat, Nov 11 2006 16:29:58):

v.digit should be(come) friendly and run v.build (or the equivalent C stuff)
to reconstruct the topology.

That's one thing. The other is that it shows that v.digit crashes at startup
if the region is particulary big. Eg. if in spearfish I do:

$ g.region s=0 n=999999999 w=0 e=999999999 res=1 -a

v.digit fails as follows:

$ v.digit -n test
New empty map created.
ERROR: G_malloc: out of memory

In a communication offlist Guido Lorenz (the reporter) confirms this with his
dataset.

Maciek

-------------------------------------------- Managed by Request Tracker

2

Maciek Sieczka via RT wrote:

That's one thing. The other is that it shows that v.digit crashes at
startup if the region is particulary big. Eg. if in spearfish I do:

$ g.region s=0 n=999999999 w=0 e=999999999 res=1 -a

v.digit fails as follows:

$ v.digit -n test
New empty map created.
ERROR: G_malloc: out of memory

In a communication offlist Guido Lorenz (the reporter) confirms this
with his dataset.

can this be reproduced with a realistic region size?

(I'm not saying it isn't something that shouldn't be looked into, but
I'm not too worried about GRASS failing gracefully when the user has
defined a region bigger than their system can handle, ~ 100,000 x
100,000 cells (40gb?))

Hamish

3

Hamish wrote:

can this be reproduced with a realistic region size?

(I'm not saying it isn't something that shouldn't be looked into, but
I'm not too worried about GRASS failing gracefully when the user has
defined a region bigger than their system can handle, ~ 100,000 x
100,000 cells (40gb?))

By setting the region (no matter how big) you don't create any "40 GB
data". And you don't create any such huge dataset either by running
'v.digit -n test' and drawing a line. IOW, there is no reason v.digit
should crash in the given circumstances.

Maciek

4

[ http://intevation.de/rt/webrt?serial_num=5264 ]

v.digit -n map=testv2
New empty map created.
ERROR: G_malloc: out of memory

Maciej Sieczka wrote:

Hamish wrote:

> can this be reproduced with a realistic region size?
>
> (I'm not saying it isn't something that shouldn't be looked into,
> but I'm not too worried about GRASS failing gracefully when the user
> has defined a region bigger than their system can handle, ~ 100,000
> x 100,000 cells (40gb?))

By setting the region (no matter how big) you don't create any "40 GB
data". And you don't create any such huge dataset either by running
'v.digit -n test' and drawing a line. IOW, there is no reason v.digit
should crash in the given circumstances.

shouldn't .. and yet it does.

fwiw,

grass63/vector/v.digit$ grep G_malloc *
cat.c: MaxFieldCat = (void *) G_malloc ( (aMaxFieldCat) * sizeof(int) * 2 );
symb.c: LineSymb = (int *) G_malloc ( (aLineSymb + 1) * sizeof(int) );
symb.c: NodeSymb = (int *) G_malloc ( (aNodeSymb + 1) * sizeof(int) );

you'd have to run it through the debugger to find which G_malloc call is
the guilty one. (or if it's from another lib fn call external to
v.digit)

for me, I can set the res this fine before it crashes: (spearfish)

# v.digit still works
G63> g.region res=0.0002 -p
nsres: 0.0002
ewres: 0.0002
rows: 69900000
cols: 94950000
cells: 6637005000000000

#v.digit crashes
G63> g.region res=0.0001 -p
..
nsres: 0.0001
ewres: 0.0001
rows: 139800000
cols: 189900000
cells: 26548020000000000

after that setting res back to 10m doesn't help. I always get the error
until restarting GRASS. I guess the # of cells is overflowing into a
static variable? or more probably just generally breaking the
G_get_window() & co calls ??

again, these region settings are totally unrealistic, but cleaning up
after bogus region settings shouldn't break the entire grass session.

Hamish