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

[Dylan Beaudette]

On Sat, Apr 12, 2008 at 1:15 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
>
>  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>


Thanks for the tips Gylnn.

Some tests:

1. everything _but_ lib/gis compiled with "-O2"
make -C lib/gis clean
make -C lib/gis CFLAGS1='-g -O0'

(segmentation fault)

2. make everything _but_ lib/gis and general/manage with "-O2":
make -C lib/gis clean
make -C lib/gis CFLAGS1='-g -O0'

make -C general/manage/ clean
make -C general/manage/ CFLAGS1='-g -O0'

(NO segfault)

3. make everything _but_ general/manage with "-O2":
make -C lib/gis clean
make -C lib/gis CFLAGS1='-g -O2'

make -C general/manage/ clean
make -C general/manage/ CFLAGS1='-g -O0'

(NO segfault)

4. enable optimization on general/manage: (everything else compiled with -O2)

make -C general/manage clean
make -C general/manage CFLAGS1='-g -O2'

(segfault)

5. test with -O1:
make -C general/manage clean
make -C general/manage CFLAGS1='-g -O1'

(segfault)

... so it looks like something in general/manage is screwed up by
optimization. Incrementally adding optimization:

make -C general/manage/cmd/ clean
make -C general/manage/cmd/ CFLAGS1='-g -O0'

(segfault)


# test separately:
make -C general/manage/cmd/ clean
make -C general/manage/cmd/ CFLAGS1='-g -O2'

make -C general/manage/lib/ clean
make -C general/manage/lib/ CFLAGS1='-g -O0'

(segfault)


# reset
make -C general/manage clean
make -C general/manage CFLAGS1='-g -O0'

(NO segfault)


Final thoughts: something in 'general/manage' . I can't really
speculate any further.