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

[Glynn Clements]

GRASS GIS wrote:

> #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):
> 
>  Replying to [comment:6 glynn]:
>  > Replying to [comment:5 dylan]:
>  > > I have attached two strace logs, one from the working version of
>  g.copy (-O0), and one from the non-working version (-O1).
>  >
>  > strace doesn't provide enough detail for this kind of problem. All that
>  can be deduced from the backtraces is that the segfault occurs sometime
>  after the "cell" files are closed (recursive_copy(),
>  general/manage/lib/do_copy.c:152) but before the access() test for whether
>  the cellhd file exists (G__make_mapset_element(), lib/gis/mapset_msc.c:60,
>  called from do_copy(), general/manage/lib/do_copy.c:42).
>  >
>  > AFAICT, the segfault could be occurring in recursive_copy(),
>  G_verbose(), G__make_mapset_element() or do_copy().
>  >
>  > A gdb C backtrace would be more useful, even if it isn't enough to
>  pinpoint the problem. A C backtrace will still report the correct
>  function; it just won't necessarily report the correct line number, or the
>  actual state of any variables (it *might* get this information right, but
>  as you can't tell whether the information is accurate, it doesn't
>  necessarily help).
> 
>  Thanks for the tips Glynn. Any further hints on how to do the above?

	$ gdb g.copy
	> run rast=t1,t1_copy --o

When it stops due to the segfault:

	> where
	> quit

>  > Also, it would be useful to know whether the problem occurs when lib/gis
>  is compiled with optimisation or when general/manage is compiled with
>  optimisation.
> 
>  After the configure step, how can I disable optimization for specific
>  parts of the source tree?

First, compile everything. Then, re-compile specific parts with
different flags using e.g.:

	make -C lib/gis clean
	make -C lib/gis CFLAGS1='-g -O0'

-- 
Glynn Clements <glynn at gclements.plus.com>