Fri, Nov 10 2006
02:31:16
|
|
Request created by guest
|
|
Subject: v.digit - G_malloc out of memory error
Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
v.digit does not respond, trying to create a new vector file results in the following
error:
v.digit -n map=testv2
New empty map created.
ERROR: G_malloc: out of memory
When trying to edit an existing vector file, the following message appears:
v.digit map=filename
ERROR: Cannot open old vector filename4@PERMANENT on level 2
Sincerely,
Guido Lorenz
------------------
glorenz2000@yahoo.com |
|
Fri, Nov 10 2006
18:50:12
|
|
Mail sent by msieczka
|
|
guest wrote (Fri, Nov 10 2006 02:31:16):
> trying to create a new vector file results in the following error:
>
> v.digit -n map=testv2
> New empty map created.
> ERROR: G_malloc: out of memory
Hi, thanks for the report. v.digit works for me. Nobody seems to be confirming
this bug. So a few questions:
GRASS version exactly?
Linux?
region settings?
tcl/tk version (build time and run time, if different)?
> When trying to edit an existing vector file, the following message appears:
>
> v.digit map=filename
> ERROR: Cannot open old vector filename4@PERMANENT on level 2
That's because v.digit crashes and leaves the vector without topology.
Thanks,
Maciek
|
|
Sat, Nov 11 2006
16:29:58
|
|
Mail sent by neteler@itc.it
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
X-AuditID |
d94d5003-ab9f9bb000000fbc-a4-4555ec73b7f7
|
Date |
Sat, 11 Nov 2006 16:29:54 +0100
|
From |
Markus Neteler <neteler@itc.it>
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] [bug #5264] (grass) v.digit - G_malloc out of memory error
|
Message-ID |
<20061111152954.GB28732@bartok.itc.it>
|
Mail-Followup-To |
Maciek Sieczka via RT <grass-bugs@intevation.de>, grass-dev@grass.itc.it
|
References |
<20061110175012.E0CE41005C8@lists.intevation.de>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
In-Reply-To |
<20061110175012.E0CE41005C8@lists.intevation.de>
|
User-Agent |
Mutt/1.4.2.2i
|
X-PGP-Key |
http://www.gdf-hannover.de/neteler/markus_gpgkey.asc
|
X-PGP-Fingerprint |
D4D5 2F80 120E AD60 E2F6 2297 21B3 D02B E1E7 E789
|
X-Brightmail-Tracker |
AAAAAA==
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
On Fri, Nov 10, 2006 at 06:50:12PM +0100, Maciek Sieczka via RT wrote:
...
> > When trying to edit an existing vector file, the following message appears:
> >
> > v.digit map=filename
> > ERROR: Cannot open old vector filename4@PERMANENT on level 2
>
> That's because v.digit crashes and leaves the vector without topology.
v.digit should be(come) friendly and run v.build (or the equivalent C stuff)
to reconstruct the topology.
Markus
|
|
Sat, Nov 11 2006
20:50:20
|
|
Mail sent by msieczka
|
|
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
|
|
Sun, Nov 12 2006
04:50:31
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Sun, 12 Nov 2006 16:46:13 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Cc |
glorenz2000@yahoo.com, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] [bug #5264] (grass) v.digit - G_malloc out of memory error
|
Message-Id |
<20061112164613.5f2f4725.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20061111195021.049A11005A3@lists.intevation.de>
|
References |
<20061111195021.049A11005A3@lists.intevation.de>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-2.3 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7]
|
X-Spam-Level |
|
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
|
|
Sun, Nov 12 2006
16:10:09
|
|
Mail sent by tutey@o2.pl
|
|
Return-Path |
<tutey@o2.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<45573946.9090500@o2.pl>
|
Date |
Sun, 12 Nov 2006 16:09:58 +0100
|
From |
Maciej Sieczka <tutey@o2.pl>
|
User-Agent |
Thunderbird 1.5.0.7 (X11/20060922)
|
MIME-Version |
1.0
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
Maciek Sieczka via RT <grass-bugs@intevation.de>, glorenz2000@yahoo.com, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] [bug #5264] (grass) v.digit - G_malloc out of memory error
|
References |
<20061111195021.049A11005A3@lists.intevation.de> <20061112164613.5f2f4725.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20061112164613.5f2f4725.hamish_nospam@yahoo.com>
|
Content-Type |
text/plain; charset=ISO-8859-2
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
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
|
|
Mon, Nov 13 2006
07:00:33
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 13 Nov 2006 18:02:50 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciej Sieczka <tutey@o2.pl>
|
Cc |
grass-bugs@intevation.de, glorenz2000@yahoo.com, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] [bug #5264] (grass) v.digit - G_malloc out of memory error
|
Message-Id |
<20061113180250.27cf1fa3.hamish_nospam@yahoo.com>
|
In-Reply-To |
<45573946.9090500@o2.pl>
|
References |
<20061111195021.049A11005A3@lists.intevation.de> <20061112164613.5f2f4725.hamish_nospam@yahoo.com> <45573946.9090500@o2.pl>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-2.3 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7]
|
X-Spam-Level |
|
[ 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
|
|
Mon, Nov 13 2006
10:17:22
|
|
Mail sent by msieczka
|
|
hamish_nospam@yahoo.com wrote (Mon, Nov 13 2006 07:00:33):
> again, these region settings are totally unrealistic,
No. It is quite likely anybody will sometimes set bogus region settings using
eg. g.region, and run v.digit after that (I can also imagine a user who really
wants the resolution that high, and he knows what he's doing).
> but cleaning up after bogus region settings shouldn't break the entire grass
> session.
That's one thing. But first of all v.digit mustn't crash and corrupt my data
because it doesn't like the region settings. If it really can't handle a given
extent, it should exit cleanly.
More
|
|