[GRASS-dev] Re: [GRASS GIS] #718: r.li forgets mask/illegal filename

GRASS GIS trac at osgeo.org
Mon Aug 17 01:00:47 EDT 2009

#718: r.li forgets mask/illegal filename
  Reporter:  kyngchaos  |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect     |      Status:  new                      
  Priority:  normal     |   Milestone:  6.4.0                    
 Component:  Raster     |     Version:  6.4.0 RCs                
Resolution:             |    Keywords:  r.li                     
  Platform:  All        |         Cpu:  All                      
Comment (by hamish):

 ok, I can reproduce this now. The conf file above doesn't trigger it
 because it sets up a moving window which covers the whole map. You need to
 use r.li.setup to make a subsampled window to have it happen. (???)

 NC sample dataset / 'g.region rast=landclass96'
 SAMPLINGFRAME 0.311787072243|0.18776371308|0.341772151899|0.376425855513
 SAMPLEAREA 0.366920152091|0.259493670886|0.0443037974684|0.0361216730038
 SAMPLEAREA 0.587452471483|0.42194092827|0.0443037974684|0.0437262357414
 SAMPLEAREA 0.32319391635|0.42194092827|0.0886075949367|0.041825095057

 G65> r.li.shannon map=landclass96 conf=landclass96_conf2
 output=landclass96_shannon --o --v
 *** glibc detected *** malloc(): memory corruption: 0x09166940 ***
 D0/0: daemon while loop: toReceive.type=-1208818294
 Illegal filename. Character <   > not allowed.
 Illegal filename. Character <   > not allowed.
 Illegal filename. Character <   > not allowed.
 WARNING: Unable to open header file for raster map < @(null)>
 CHILD[pid = 20559]: unable to open < > mask ... continuing without!

 (I added that debug msg locally)

 code updated in 6.5svn and 7svn to fail more gracefully if the type value
 is garbage. (in r38757 and r38758)

 hmmph but now that I try gdb that memory has something else in it which
 doesn't trigger the breakage. I'll have to come back to it later.


 I suspect there may be some bad inefficency in that worker.c receive()
 while loop, perhaps explaining the 50% of proc time spent in the kernel
 for at least the moving window conf file (found in comment:3).

 perhaps the alloc()s within each iteration of the loop? especially for the
 moving window mode which will cycle through the loop many, many times. And
 no G_free()?


 also I notice that the ~/.r.li/output/conf_filename file is created with
 the exe bit set for some reason?!:
 daemon.c:138:   sprintf(out, "%s/.r.li/output/%s", getenv("HOME"),
 daemon.c-139:   res = open(out, O_WRONLY | O_CREAT | O_TRUNC, 0755);

 should that be 0644 or better yet just left to the system? (how, by just
 removing the 0755?)


Ticket URL: <https://trac.osgeo.org/grass/ticket/718#comment:15>
GRASS GIS <http://grass.osgeo.org>

More information about the grass-dev mailing list