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
> ----------------------+-----------------------------------------------------
> Changes (by dylan):
>
> * summary: g.copy segfaults (debian.gfoss.it package) => g.copy
> segfaults (debian.gfoss.it package) [and latest
> SVN]
>
> Comment:
>
> Ouch. This bug has been biting me for a while now. How can optimization
> cause a segfault for {{{g.copy rast=rast1,rast2}}} but not for {{{g.copy
> vect=vect1,vect2}}} ?
For vectors, the copying is performed by calling Vect_copy(). For all
other types, g.copy copies the files itself.
> This sounds like a nasty bug to me.
Unfortunately, it isn't likely to get fixed unless someone who can get
the segfault to occur can debug it, at least to the extent of
identifying exactly where the segfault occurs.
As it only occurs with optimisation enabled, it will probably need to
be debugged in assembler ("set language asm"), as GDB cannot reliably
relate execution to the source code for optimised code (the structure
of optimised code often bears little resemblence to the source code).
--
Glynn Clements <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
