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

Glynn Clements glynn at gclements.plus.com
Fri Apr 11 14:57:37 EDT 2008


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                   
> ----------------------+-----------------------------------------------------
> 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 <glynn at gclements.plus.com>


More information about the grass-dev mailing list