On Sat, Apr 12, 2008 at 1:15 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
GRASS GIS wrote:
> #50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]
> ----------------------+-----------------------------------------------------
> Reporter: steko | Owner: grass-dev@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@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.
