[GRASS-dev] [GRASS GIS] #1632: v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed. in the same projection

[GRASS GIS]

#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>