[GRASS-dev] [GRASS GIS] #3690: r.stats.quantile crashing with data linked through r.external

[GRASS GIS]

#3690: r.stats.quantile crashing with data linked through r.external
------------------------------------------+--------------------------------
 Reporter:  neteler                       |      Owner:  grass-dev@…
     Type:  defect                        |     Status:  new
 Priority:  normal                        |  Milestone:  7.4.3
Component:  Raster                        |    Version:  svn-
                                          |  releasebranch74
 Keywords:  r.external, r.stats.quantile  |        CPU:  Unspecified
 Platform:  Unspecified                   |
------------------------------------------+--------------------------------
 We discovered that r.stats.quantile crashes with data linked through
 r.external (when importing the same data sets with r.in.gdal it works
 fine).

 It seems that a corruption occurs with GDAL?


 {{{
 GRASS 7.4.3svn (utm30N):  > r.external input="covermap.tif" band=1
 output=tmp15409185587112 --overwrite -o
 Reading band 1 of 1...
 r.external komplett. Link to raster map <tmp15409185587112> created.

 GRASS 7.4.3svn (utm30N):  > r.external input="basemap.tif" band=1
 output=tmp15409185587113 --overwrite -oÜ
 Reading band 1 of 1...
 r.external komplett. Link to raster map <tmp15409185587113> created.

 GRASS 7.4.3svn (utm30N):  > r.stats.quantile -p base="tmp15409185587112"
 cover="tmp15409185587113" bins="2000"
 Computing histograms
  100%
 Speicherzugriffsfehler (Speicherabzug geschrieben)
 }}}

 ... i.e. Core dump.

 Debugging:
 {{{
 GRASS 7.4.3svn (utm30N):  > gdb r.stats.quantile
 GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
 ...
 (gdb) r -p base="tmp15409185587112" cover="tmp15409185587113" bins="2000"
 Starting program: /home/user/src/grass-7.4.svn/dist.x86_64-pc-linux-
 gnu/bin/r.stats.quantile -p base="tmp15409185587112"
 cover="tmp15409185587113" bins="2000"
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
 Computing histograms
  100%
   27%
 Program received signal SIGSEGV, Segmentation fault.
 0x0000000000401fa0 in get_slot_counts (basefile=0, coverfile=1) at
 main.c:161
 161                 bc->slots[i]++;


 (gdb) bt
 #0  0x0000000000401fa0 in get_slot_counts (basefile=0, coverfile=1) at
 main.c:161
 #1  0x0000000000403c89 in main (argc=5, argv=0x7fffffffd878) at main.c:642


 (gdb) bt full
 #0  0x0000000000401fa0 in get_slot_counts (basefile=0, coverfile=1) at
 main.c:161
         basebuf = 0x6c5760
         coverbuf = 0x6c6eb0
         bc = 0x6f3ab0
         row = 467
         col = 1305
         i = 0
         allnull = 0
 #1  0x0000000000403c89 in main (argc=5, argv=0x7fffffffd878) at main.c:642
         module = 0x7ffff7ba0ea8 <state+40>
         opt = {quant = 0x640ec0, perc = 0x641000, slots = 0x641140,
 basemap = 0x7ffff7ba0f08 <state+136>, covermap = 0x640d80, output =
 0x641280, file = 0x641440, fs = 0x641640}
         flag = {r = 0x7ffff7ba0ed8 <state+88>, p = 0x6426a0, t = 0x6426d0}
         basemap = 0x61edb0 "tmp15409185587112"
         covermap = 0x61ee80 "tmp15409185587113"
         outputs = 0x0
         fs = 0x7fffffffd72f "@"
         reclass = 0
         print = 1
         cover_fd = 1
         base_fd = 0
         range = {min = 1, max = 1061, first_time = 0}
         fprange = {min = 7.0767250061034996, max = 9.9984693527221999,
 first_time = 0}
         i = 1
 (gdb)
 }}}

 Looking at memory allocation and G_free() usage, I see that not all is
 freed:

 {{{
 cd r.stats.quantile/
 grep 'G_calloc\|G_free' main.c  | grep bc
         bc->slots = G_calloc(bc->num_slots, sizeof(unsigned int));
         bc->bins = G_calloc(num_quants, sizeof(struct bin));
         bc->slot_bins = G_calloc(bc->num_slots, sizeof(unsigned char));
         G_free(bc->slots);
         bc->values = G_calloc(num_values, sizeof(DCELL));
         G_free(bc->slot_bins);

 }}}

 but I am not sure if that is related.

 We can make the two GeoTIFF files offlist available.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/3690>
GRASS GIS <https://grass.osgeo.org>