[GRASS-dev] Aborted (core dumped), during v.build

GRASS GIS GRASS GIS developer
1

Hi,

I'm trying to convert a segment map into a vector map, I'm using GRASS7 (r58321), but I got:

G70> r.to.vect --o --v input=seg_0.05_final@pietro output=seg005 type=area
WARNING: Vector map <seg005> already exists and will be overwritten
Using native format
Extracting areas...
100%
Writing areas...
100%
Building topology for vector map <seg005@pietro>...
Registering primitives...
Unexpected error.
Aborted (core dumped)

G70> v.info map=seg005
WARNING: Coor file of vector map <seg005@pietro> is larger than it should
         be (3198718980 bytes excess)
+----------------------------------------------------------------------------+
| Name: seg005 |
| Mapset: pietro |
| Location: combabula |
| Database: /home/pietro |
| Title: |
| Map scale: 1:1 |
| Name of creator: pietro |
| Organization: |
| Source date: Thu Nov 28 20:55:18 2013 |
| Timestamp (first layer): none |
|----------------------------------------------------------------------------|
| Map format: native |
|----------------------------------------------------------------------------|
| Type of map: vector (level: 1) |
| |
| Number of points: 0 Number of centroids: 5970928 |
| Number of lines: 0 Number of boundaries: 16325866 |
| Number of areas: 0 Number of islands: 0 |
| |
| Map is 3D: No |
| Number of dblinks: 1 |
| |
| Projection: UTM (zone invalid) |
| |
| N: 7104206.80119541 S: 7089186.6842956 |
| E: 759827.4950082 W: 745280.94984459 |
| |
| Digitization threshold: 0 |
| Comment: |
| |
+----------------------------------------------------------------------------+

the problem raise when I try to build the topography, running v.build I got:

G70> v.build map=seg005 --v
WARNING: Coor file of vector map <seg005@pietro> is larger than it should
         be (3198718980 bytes excess)
Building topology for vector map <seg005@pietro>...
Registering primitives...
22296794 primitives registered
189966723 vertices registered
Building areas...
Unexpected error.
Aborted (core dumped)

What it is wrong and how to fix it? Any ideas?

Best regards

Pietro

2

Il giorno 29/nov/2013 00:45, “Pietro Zambelli” <peter.zamb@gmail.com> ha scritto:

Hi,

Ciao Pietro,

What it is wrong and how to fix it? Any ideas?

Please try make distclean,I had similar problems some day ago

Best regards

Pietro

Ciao
Luca

3

On Friday 29 Nov 2013 06:54:59 you wrote:

> What it is wrong and how to fix it? Any ideas?

Please try make distclean,I had similar problems some day ago

I did, actually, so should be something else I guess...

Pietro

4

Hi Pietro,

2013/11/29 Pietro Zambelli <peter.zamb@gmail.com>:

On Friday 29 Nov 2013 06:54:59 you wrote:

> What it is wrong and how to fix it? Any ideas?

Please try make distclean,I had similar problems some day ago

I did, actually, so should be something else I guess...

please could you provide more detailed info using gdb [1] ?

Martin

[1] http://grasswiki.osgeo.org/wiki/Debug#Using_GDB

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

5

Hi Martin,

On Friday 29 Nov 2013 09:30:10 Martin wrote:

> I did, actually, so should be something else I guess...

please could you provide more detailed info using gdb [1] ?

ok, I attached the gdb result... I try also with valgrind but didn't work it
terminated with this odd message:

==2885==
==2885== Valgrind's memory management: out of memory:
==2885== memcheck:allocate new SecMap's request for 16384 bytes failed.
==2885== 6948536320 bytes have already been allocated.
==2885== Valgrind cannot continue. Sorry.
==2885==
==2885== There are several possible reasons for this.
==2885== - You have some kind of memory limit in place. Look at the
==2885== output of 'ulimit -a'. Is there a limit on the size of
==2885== virtual memory or address space?
==2885== - You have run out of swap space.
==2885== - Valgrind has a bug.
[cut]
==2885==
==2885== Whatever the reason, Valgrind cannot continue. Sorry.

this is the result of:

$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 30
file size (blocks, -f) unlimited
pending signals (-i) 192592
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 99
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 192592
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

That it seems ok to me.

The current machine, that I'm using for testing, has 24Gb of ram and 8 Gb of
swap, when I was using valgrind the consume of memory was under 6 Gb, rather
than using gdb was around 12Gb.

However, I reduced the number of segments increasing the minsize variable of
the i.segment module and it works:

G70> r.to.vect --o --v input=seg_0.05_final_64@pietro output=seg005_64
type=area
Using native format
Extracting areas...
100%
Writing areas...
100%
Building topology for vector map <seg005_64@pietro>...
Registering primitives...
10552849 primitives registered
140744636 vertices registered
Building areas...
100%
2774561 areas built
125253 isles built
Attaching islands...
100%
Attaching centroids...
100%
Topology was built
Number of nodes: 5128980
Number of primitives: 10552849
Number of points: 0
Number of lines: 0
Number of boundaries: 7778288
Number of centroids: 2774561
Number of areas: 2774561
Number of isles: 125253
r.to.vect complete.

So maybe it is the high number of primitives that crash the module.
Do you see any other reason from the gdb backtrace?

thank you for the help

Pietro

(attachments)

vbuild_gdb.txt (15.3 KB)
vbuild_valgrind.txt (54.2 KB)

6

It looks very much like an out-of-memory error. In the gdb backtrace I see

#4 0x00007ffff6601ebd in RTreeNewListBranch (t=0x609c30) at node.c:441
        p = 0x0

which means that memory allocation failed.

Try

export GRASS_VECTOR_LOWMEM=1
r.to.vect --o --v input=seg_0.05_final@pietro output=seg005 type=area

Markus M