#1632: v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed. in
the same projection
----------------------+-----------------------------------------------------
Reporter: pertusus | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Component: Vector | Version: 6.4.2
Keywords: | Platform: Linux
Cpu: x86-64 |
----------------------+-----------------------------------------------------
I have a vector map of lines I did myself (automatically, though), in the
grass ascii format. In one location I import it with v.in.ascii with
format=standard and everything seems fine.
When I project to a location that is exactly in the same projection,
however, I get
{{{
v.proj potential_reservoir_demands_links location=proj_location
Building topology for vector map <potential_reservoir_demands_links>...
Registering primitives...
v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed.
}}}
I did a backtrace in gdb
{{{
(gdb) run
Starting program: /usr/lib64/grass-6.4.2/bin/v.proj
potential_reservoir_demands_links location=proj_location
[Thread debugging using libthread_db enabled]
Building topology for vector map <potential_reservoir_demands_links>...
Registering primitives...
v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed.
Program received signal SIGABRT, Aborted.
0x0000003fdb432885 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003fdb432885 in raise () from /lib64/libc.so.6
#1 0x0000003fdb434065 in abort () from /lib64/libc.so.6
#2 0x0000003fdb42b9fe in __assert_fail_base () from /lib64/libc.so.6
#3 0x0000003fdb42bac0 in __assert_fail () from /lib64/libc.so.6
#4 0x000000314f802fcb in RTreeClassify (i=0, group=<value optimized out>,
p=0x314fa04be0) at split_q.c:69
#5 0x000000314f803519 in RTreePickSeeds (n=0xb29a70, b=<value optimized
out>, nn=0x7fffffffca68) at split_q.c:114
#6 RTreeMethodZero (n=0xb29a70, b=<value optimized out>,
nn=0x7fffffffca68) at split_q.c:230
#7 RTreeSplitNode (n=0xb29a70, b=<value optimized out>,
nn=0x7fffffffca68) at split_q.c:307
#8 0x000000314f80225c in RTreeAddBranch (B=<value optimized out>,
N=<value optimized out>, New_node=<value optimized out>)
at node.c:201
#9 0x000000314f801a9b in RTreeInsertRect2 (r=0x7fffffffce50,
child=0x5a3a, n=0xb29a70, new_node=0x7fffffffca68,
level=<value optimized out>) at index.c:121
#10 0x000000314f801b15 in RTreeInsertRect2 (r=0x7fffffffce50,
child=0x5a3a, n=0xb2d270, new_node=0x7fffffffcb28,
level=<value optimized out>) at index.c:102
#11 0x000000314f801b15 in RTreeInsertRect2 (r=0x7fffffffce50,
child=0x5a3a, n=0xae3c90, new_node=0x7fffffffcbe8,
level=<value optimized out>) at index.c:102
#12 0x000000314f801b15 in RTreeInsertRect2 (r=0x7fffffffce50,
child=0x5a3a, n=0xb0fd40, new_node=0x7fffffffcca8,
level=<value optimized out>) at index.c:102
#13 0x000000314f801b15 in RTreeInsertRect2 (r=0x7fffffffce50,
child=0x5a3a, n=0xa90b80, new_node=0x7fffffffcd68,
level=<value optimized out>) at index.c:102
#14 0x000000314f801b15 in RTreeInsertRect2 (r=0x7fffffffce50,
child=0x5a3a, n=0x946320, new_node=0x7fffffffce18,
level=<value optimized out>) at index.c:102
#15 0x000000314f801d00 in RTreeInsertRect1 (R=<value optimized out>,
Child=<value optimized out>, Root=0x7fffffffd2c0,
Level=<value optimized out>) at index.c:162
#16 0x000000315040d609 in dig_spidx_add_line (Plus=0x7fffffffd0b0,
line=23098, box=0x7fffffffceb0) at spindex.c:160
#17 0x0000003150409350 in add_line (plus=0x7fffffffd0b0, lineid=23098,
type=2, Points=0x60acf0, offset=854603)
at plus_line.c:83
#18 0x0000003150409520 in dig_add_line (plus=0x7fffffffd0b0, type=2,
Points=<value optimized out>,
offset=<value optimized out>) at plus_line.c:114
#19 0x00000034f7815bed in Vect_build_nat (Map=0x7fffffffd0a0, build=4) at
build_nat.c:537
#20 0x00000034f7814686 in Vect_build_partial (Map=0x7fffffffd0a0, build=4)
at build.c:134
#21 0x0000000000402366 in main (argc=6326848, argv=0x608a40) at main.c:300
}}}
It is reproducible, but I also do the same for different maps and on
different locations (all Lambert) and it leads to the assertion only in
one case.
I attach a tarball that allows to reproduce the issue.
After expanding and cd'ing into, you should adjust the path to grass in
and proj.sh. Then run
{{{
./do_all.sh
}}}
which simply runs ./prepare_location.sh that does the v.in.ascii and then
./proj.sh that does the v.proj.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1632>
GRASS GIS <http://grass.osgeo.org>