[GRASS-dev] Re: [GRASS GIS] #736: r.proj fails in wingrass

[GRASS GIS]

#736: r.proj fails in wingrass
------------------------------+---------------------------------------------
  Reporter:  cnielsen         |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect           |      Status:  closed                   
  Priority:  normal           |   Milestone:  6.4.0                    
 Component:  Raster           |     Version:  unspecified              
Resolution:  fixed            |    Keywords:  r.proj, wingrass         
  Platform:  MSWindows Vista  |         Cpu:  x86-32                   
------------------------------+---------------------------------------------
Comment (by jef):

 Replying to [comment:12 hamish]:
 > ps- I still would like to learn a bit more about how to deal with there
 errors which Valgrind finds; leaving them there but ignoring them seems
 like an unscratched itch. Currently I can make the reports but it's
 frustrating having done that not knowing what to do next.

 Without reviewing the valgrind log in detail, I'd just expect memory
 leaks.  Those just waste memory and are otherwise harmless, unless you run
 out of memory because of them.

 It didn't point to the crash.  Actually it can't as there isn't any
 problem valgrind could detect, because on Unix there isn't any.  On Unix
 the runtime library (aka libc) provides {{{malloc()}}} and {{{free()}}}
 and deals with memory management for the whole process - including shared
 libraries.

 On Windows OTOH each DLL can have it's own runtime library and each call
 to {{{malloc()}}} must be matched with a call to {{{free()}}} from the
 same library.
 Therefore each DLL provides a function to free allocated memory they
 return, that simply calls {{{free()}}}, but from the runtime library they
 use - eg. {{{pj_dalloc()}}} for PROJ, {{{CPLFree()}}} for GDAL/OGR and
 {{{G_free()}}} for GRASS).

 Still you won't run into problems if you compile everything using the same
 runtime library, eg. one version of MinGW.

 On Unix one could also call any of those or {{{free()}}} directly, without
 causing problems.  But one still shouldn't as the functions might do more
 than just {{{free()}}} in the future.  That's also why I'd consider those
 issues bugs even on Unix.

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