[GRASS-dev] [GRASS GIS] #1214: r.li.edgedensity: segmentation fault

[GRASS GIS]

#1214: r.li.edgedensity: segmentation fault
------------------------------+---------------------------------------------
 Reporter:  neteler           |       Owner:  grass-dev@…              
     Type:  defect            |      Status:  new                      
 Priority:  normal            |   Milestone:  6.4.4                    
Component:  Raster            |     Version:  svn-releasebranch64      
 Keywords:  r.li.edgedensity  |    Platform:  Linux                    
      Cpu:  x86-64            |  
------------------------------+---------------------------------------------

Comment(by hamish):

 Replying to [comment:4 rashadkm]:
 > edegedensity and patchdensity fails for me in grass70 and
 > works in grass65 and grass64
 > svn revision: 58968
 > location: nc_spm_08
 > mapset: PERMANENT
 >
 > {{{
 > r.li.patchdensity map=geology conf=geology_mov output=pdens_out
 > r.li.edgedensity map=geology conf=geology_mov output=edens_out
 > }}}
 >
 > geology_mov:
 > {{{
 > SAMPLINGFRAME 0|0|1|1
 > SAMPLEAREA -1|-1|0.03571428571428571|0.02631578947368421
 > MOVINGWINDOW
 > }}}


 I'll start with this one, both fail for me in grass7 too.

 r.li.edgedensity segfaults in Rast_get_cellhd():

 {{{
 (gdb) list
 78      {
 79          struct Cell_head hd;
 80          int ris = -1;
 81          double indice = 0;
 82
 83          Rast_get_cellhd(ad->raster, "", &hd);
 84
 85          switch (ad->data_type) {
 86          case CELL_TYPE:
 87              {
 }}}

 on the fifth pass into the function, although I'm not sure why, 'hd' is
 defined only a few lines earlier and `ad->raster` seems ok and the same
 setup as r.li.patchdensity.  (weirdness generally makes me suspect the
 stack getting smashed sometime earlier)

 ----
 I can get r.li.patchdensity to work in grass7 if I comment out the
 `G_free(sup);` at the very end of main.c, but then of course it leaks
 memory for every row of raster data. I notice in `top` that while it's
 running 5-10% of the CPU time is spent for the system: there's something
 horribly inefficient going on internally.

 I'd also note while visually similar the r.li.patchdensity raster output
 is numerically different from G6.5's r.li.patchdensity run with the same
 input files, so beware in trusting the results.

 Again, the valgrind errors are probably a good place to start:

 {{{
 ==15739==
 ==15739== Conditional jump or move depends on uninitialised value(s)
 ==15739==    at 0x4E2FA8D: RLI_get_cell_raster_row (worker.c:256)
 ==15739==    by 0x4010B0: patch_density (main.c:101)
 ==15739==    by 0x4E2F763: worker_process (worker.c:179)
 ==15739==    by 0x4E2CF2A: calculateIndex (daemon.c:133)
 ==15739==    by 0x400EB4: main (main.c:54)
 ==15739==
 ==15739== Invalid read of size 4
 ==15739==    at 0x401316: patch_density (main.c:153)
 ==15739==    by 0x4E2F763: worker_process (worker.c:179)
 ==15739==    by 0x4E2CF2A: calculateIndex (daemon.c:133)
 ==15739==    by 0x400EB4: main (main.c:54)
 ==15739==  Address 0x62e7464 is 4 bytes inside a block of size 2,004
 free'd
 ==15739==    at 0x4C240FD: free (vg_replace_malloc.c:366)
 ==15739==    by 0x526F1A6: G_free (alloc.c:151)
 ==15739==    by 0x4015E8: patch_density (main.c:205)
 ==15739==    by 0x4E2F763: worker_process (worker.c:179)
 ==15739==    by 0x4E2CF2A: calculateIndex (daemon.c:133)
 ==15739==    by 0x400EB4: main (main.c:54)
 ==15739==
 (many more)
 ...

 Program received signal SIGABRT, Aborted.

 (gdb) bt
 #0  0x00007ffff71af1b5 in *__GI_raise (sig=<value optimized out>)
     at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
 #1  0x00007ffff71b1fc0 in *__GI_abort () at abort.c:92
 #2  0x00007ffff71e55bb in __libc_message (do_abort=<value optimized out>,
     fmt=<value optimized out>) at
 ../sysdeps/unix/sysv/linux/libc_fatal.c:189
 #3  0x00007ffff71eee16 in malloc_printerr (action=3,
     str=0x7ffff72a66f8 "free(): invalid next size (fast)", ptr=<value
 optimized out>)
     at malloc.c:6267
 #4  0x00007ffff71f3b8c in *__GI___libc_free (mem=<value optimized out>) at
 malloc.c:3739
 #5  0x00007ffff776e1a7 in G_free (buf=0x6167f0) at alloc.c:151
 #6  0x00000000004015e9 in patch_density (fd=0, par=0x0, ad=0x602990,
 result=0x7ffff7dde540)
     at main.c:205
 #7  0x00007ffff7bdc764 in worker_process (ret=0x7fffffffb970,
 m=0x7fffffffba90)
     at worker.c:179
 #8  0x00007ffff7bd9f2b in calculateIndex (file=0x6026e0 "geology_mov",
     f=0x400eb7 <patch_density>, parameters=0x0, raster=0x6026c0
 "geology_30m",
     output=0x602700 "pdens_out7") at daemon.c:133
 #9  0x0000000000400eb5 in main (argc=4, argv=0x7fffffffdd78) at main.c:54

 ...

 (gdb) frame 6
 #6  0x00000000004015e9 in patch_density (fd=0, par=0x0, ad=0x602990,
 result=0x7ffff7dde540)
     at main.c:205
 205         G_free(sup);
 (gdb) list
 200         if (area != 0)
 201             *result = (count / area) * 1000000;
 202         else
 203             *result = -1;
 204
 205         G_free(sup);
 206
 207         return RLI_OK;
 208     }
 }}}


 ?

 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1214#comment:5>
GRASS GIS <http://grass.osgeo.org>