[GRASS-dev] Re: [GRASS GIS] #50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]

[GRASS GIS]

#50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]
----------------------+-----------------------------------------------------
  Reporter:  steko    |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect   |      Status:  new                      
  Priority:  major    |   Milestone:  6.4.0                    
 Component:  default  |     Version:  6.3.0 RCs                
Resolution:           |    Keywords:  g.copy                   
----------------------+-----------------------------------------------------
Comment (by dylan):

 Following Glynn's advice to try isolating the segfault to something in
 [http://trac.osgeo.org/grass/browser/grass/trunk/general/manage/lib/do_copy.c
 do_copy.c] :

 > The last "make" should re-compile do_copy.c (with -O2) and re-link
 g.copy.
 > If the problem is in do_copy.c, the resulting g.copy will segfault.

 {{{
 make -C general/manage clean
 make -C general/manage CFLAGS1='-g -O0'
 rm general/manage/lib/OBJ.*/do_copy.o
 rm dist.*/bin/g.copy
 make -C general/manage CFLAGS1='-g -O2'
 }}}

 This results in a segfault when executing g.copy rast=...

 It
 [http://trac.osgeo.org/grass/log/grass/trunk/general/manage/lib/do_copy.c?rev=23024
 looks like] g.copy was made less UNIX-dependent at some point, with the
 introduction of recursive_copy replacing cp (?). Could an out of control
 recursion be broken by compiler optimization?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/50#comment:10>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/