i.superpixels.slic fails when region larger than 500x500 pix (on Win7)

[tgrippa]

Hi,

I tested the new i.superpixels.slic add-on on the North Carolina dataset. It is very fast and interesting.

Unfortunately, when reaching a region of more than 500x500 pixels (it is what I've found), the add-on crashes.

Here after the command I used

OK:

g.remove -f type=group name=ortho

i.group group=ortho input=ortho_2001_t792_1m

g.region raster=ortho_2001_t792_1m n=219956 s=219456 e=637533 w=637033 rows=500 cols=500

g.region -p

i.superpixels.slic --overwrite group=ortho k=500 output=slic_segment

Failing:

g.remove -f type=group name=ortho

i.group group=ortho input=ortho_2001_t792_1m

g.region raster=ortho_2001_t792_1m n=219966 s=219456 e=637543 w=637033 rows=510 cols=510

g.region -p

i.superpixels.slic --overwrite group=ortho k=500 output=slic_segment

A pop-up window appears with an "APPCRASH" message saying that GRASS 7 stops working.

FYI: my PC runs with an Intel core i5-3570 CPU (64 bits) (3.4Ghz) and 32Go RAM

[tgrippa]

APPCRASH_message

[mlennert]

I can confirm segfault on Linux, but with different number of pixels:

g.region raster=ortho_2001_t792_1m n=220477 s=219456 e=638054 w=637033 res=1 -p
projection: 99 (Lambert Conformal Conic)
zone:       0
datum:      nad83
ellipsoid:  a=6378137 es=0.006694380022900787
north:      220477
south:      219456
west:       637033
east:       638054
nsres:      1
ewres:      1
rows:       1021
cols:       1021
cells:      1042441

i.superpixels.slic --overwrite group=ortho k=500 output=slic_segment

works, but

g.region raster=ortho_2001_t792_1m n=220479 s=219456 e=638056 w=637033 res=1 -p
projection: 99 (Lambert Conformal Conic)
zone:       0
datum:      nad83
ellipsoid:  a=6378137 es=0.006694380022900787
north:      220479
south:      219456
west:       637033
east:       638056
nsres:      1
ewres:      1
rows:       1023
cols:       1023
cells:      1046529

i.superpixels.slic --overwrite group=ortho k=500 output=slic_segment

gives me a segfault. 1022x1022 sometimes does, sometimes doesn't.

Here's the backtrace I get in gdb, but I guess the addon needs to be recompiled with debugging enabled:

#0  0x00007ffff70f9d3e in _IO_vfprintf_internal (s=0x7fffff7ff180, format=0x7ffff7790b7b "%4d%%\b\b\b\b\b", ap=0x7fffff801828)
    at vfprintf.c:1267
#1  0x00007ffff70fcc23 in buffered_vfprintf (s=0x7ffff744c520 <_IO_2_1_stderr_>, format=<optimized out>, args=<optimized out>)
    at vfprintf.c:2325
#2  0x00007ffff70f9f15 in _IO_vfprintf_internal (s=0x7ffff744c520 <_IO_2_1_stderr_>, format=0x7ffff7790b7b "%4d%%\b\b\b\b\b", 
    ap=ap@entry=0x7fffff801828) at vfprintf.c:1293
#3  0x00007ffff7102157 in __fprintf (stream=<optimized out>, format=format@entry=0x7ffff7790b7b "%4d%%\b\b\b\b\b")
    at fprintf.c:32
#4  0x00007ffff7780e4a in G_percent (n=0, d=10, s=<optimized out>) at percent.c:83
#5  0x0000555555555c21 in main (argc=<optimized out>, argv=<optimized out>) at main.c:338

Here's the output with g.gisenv set=DEBUG=3:

D1/3: G_find_raster2(): name=ortho_2001_t792_1m mapset=PERMANENT
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/cell/ortho_2001_t792_1m
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/fcell/ortho_2001_t792_1m
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/g3dcell/ortho_2001_t792_1m
D1/3: G_find_raster2(): name=ortho_2001_t792_1m mapset=PERMANENT
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/cell/ortho_2001_t792_1m
D1/3: G_find_raster2(): name=ortho_2001_t792_1m mapset=PERMANENT
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/cell/ortho_2001_t792_1m
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/fcell/ortho_2001_t792_1m
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/g3dcell/ortho_2001_t792_1m
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/cell_misc/ortho_2001_t792_1m/gdal
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/cell/ortho_2001_t792_1m
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/cell/ortho_2001_t792_1m
D3/3: create window mapping (1023 columns)
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/cell_misc/ortho_2001_t792_1m/null
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/cell_misc/ortho_2001_t792_1m/null
D1/3: G_find_raster(): name=MASK mapset=user1
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/user1/cell/MASK
D1/3: G_find_raster2(): name=ortho_2001_t792_1m mapset=PERMANENT
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/cell/ortho_2001_t792_1m
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/fcell/ortho_2001_t792_1m
D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/PERMANENT/g3dcell/ortho_2001_t792_1m
Erreur de segmentation

[mlennert]

No more segfault when I decomment the allocation of the distvect array in line 317-18:

@@ -314,10 +314,10 @@
   memset (sigmay, 0, sizeof (double) * numk);
 
 
-  //double *distvec;
-  //	distvec = G_malloc (sizeof (double) * sz);
+  double *distvec;
+  	distvec = G_malloc (sizeof (double) * sz);
 
-  double distvec[sz];
+  /*double distvec[sz];*/
   int p;
   for( p = 0; p < sz; p++ ) distvec[p] = 1E+9;

Don't know why this was commented, though, so I'll wait for Rashad to react.

[mlennert]

I attach a more complete patch. It also includes assigning a random color table and writing to the output file history.

Rashad, I don't want to commit because I don't know if you have been working locally on the module. Please let me know if you will do it, or if you want me to commit.

[mmetz]

Replying to mlennert:

I attach a more complete patch. It also includes assigning a random color table and writing to the output file history.

There is more to fix around L157, see also my comments in the dev ml [0]

[0] ​https://lists.osgeo.org/pipermail/grass-dev/2017-January/083745.html

[mlennert]

Replying to mmetz:

Replying to mlennert:

I attach a more complete patch. It also includes assigning a random color table and writing to the output file history.

There is more to fix around L157, see also my comments in the dev ml [0]

[0] ​https://lists.osgeo.org/pipermail/grass-dev/2017-January/083745.html

Yes, sorry, I had overlooked that you had already solved this issue and others in that mail. I don't know how much of this might become redundant when the SEG library is used.

If Rashad doesn't tell me otherwise, I'll commit your fixes + my additions later today.

[mlennert]

In 70434:

i.superpixels.slic: allocate on the heap, not the stack (fixes #3247)

[mlennert]

For now I've committed (r70434) just the fix for the segmentation fault, not the rest of the patch, so that others can work with the module.

Please test (AFAIK for Windows users you will have to wait until tomorrow to get the binary compiled) and tell us if we can close this ticket.