On Sat, Apr 12, 2008 at 1:15 PM, Glynn Clements <[EMAIL PROTECTED]> wrote: > > > GRASS GIS wrote: > > > #50: g.copy segfaults (debian.gfoss.it package) [and latest SVN] > > > > ----------------------+----------------------------------------------------- > > Reporter: steko | Owner: [email protected] > > 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 <[EMAIL PROTECTED]>
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. _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
