[GRASS5] Re: [GRASSLIST:2833] core dumps after i.rectify

[Eric G. Miller]

On Tue, 1 Jan 2002 05:10:08 +0000, Glynn Clements <glynn.clements at virgin.net> wrote:

> 
> Markus Neteler wrote:
> 
> > > After I changed 'format' from 0 to 1 everything seems to wrok fine. So
> > > i.rectify apparently sets this wrong (at least in some cases).
> > 
> > Wow - excellent. Now we have to identify the problem in i.rectify.
> > A candidate is
> > src/imagery/i.rectify2/rectify.c
> > [...]
> >    G_set_cell_format (cellhd.format);
> 
> grass at gevaerts.be wrote:
> 
> > > > After I changed 'format' from 0 to 1 everything seems to wrok fine. So
> > > > i.rectify apparently sets this wrong (at least in some cases).
> > 
> > Another possibly related problem : if the source raster is not compressed,
> > the rectified raster is compressed, but marked as not compressed.
> 
> Both of these problems seem rather odd, as src/libes/gis/closecell.c
> does this:
> 
>         if ( FCB.map_type != CELL_TYPE)
>            FCB.cellhd.format = -1;
>         else /* CELL map */
> 	   FCB.cellhd.format = FCB.nbytes - 1;
> 
> 	FCB.cellhd.compressed = (open_mode == OPEN_NEW_COMPRESSED ? 1 : 0);
> /* write header file */
>         G_put_cellhd (FCB.name, &FCB.cellhd);
> 
> IOW, both the "format" and "compressed" fields which are written to
> the "cellhd" file are being set to the values which should have been
> used in writing the "cell" file.
> 
> Unfortunately, this problem is almost impossible to track down simply
> by looking at the source. Cell_head structures are used and modified
> in far too many places, both in libgis and i.rectify, to keep track
> of. Someone will need to trace through i.rectify with a debugger,
> observing all of the changes to the format/compressed fields in all of
> the Cell_head structures.
> 
> PS: this would probably be easier if the G_fork() stuff was removed.

Alright, the problem seems to be that in "exec.c", G_put_cellhd() is
called after the raster has been written. I think it is entirely
unnecessary (and obviously screws up some critical info).  I created
an integer test file (floats didn't seem to be affected), and after
commenting the G_put_cellhd() call, the rectified image doesn't
cause a segfault.  Would others care to try... ?

It's around, line 75 or so...
        
        ...
        if (rectify (name, mapset, result,order))
        {
            select_target_env();
/*          G_put_cellhd (result,&target_window); */
            if(cats_ok)
            {
        ...

-- 
Eric G. Miller <egm2 at jps.net>