Nikos Alexandris wrote:
1st attempt to export:
> r.out.gdal in=composite_b123 out=/home/nik/grassdb/peloponnese/data/exports/composite_b123.tif
Exporting to GDAL data type: UInt16
Segmentation fault
Shouldn't the same error message (from the 1st attempt) remain?
It appears that there is a memory corruption bug somewhere, either in
r.out.gdal, the GRASS libraries, the GDAL library, or a library which
it uses.
The consequences of a memory corruption bug often depend upon the
exact memory layout, or even the exact contents of uninitialised
memory. Sometimes it will cause problems, sometimes it won't.
It doesn't help that such bugs often fail to manifest if the program
is run under a debugger (colloquially referred to as a "Heisenbug", in
reference to the quantum mechanics principle that simply observing a
system can change its behaviour).
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, 2008-09-23 at 19:55 +0100, Glynn Clements wrote:
Nikos Alexandris wrote:
> 1st attempt to export:
> > r.out.gdal in=composite_b123 out=/home/nik/grassdb/peloponnese/data/exports/composite_b123.tif
> Exporting to GDAL data type: UInt16
> Segmentation fault
> Shouldn't the same error message (from the 1st attempt) remain?
It appears that there is a memory corruption bug somewhere, either in
r.out.gdal, the GRASS libraries, the GDAL library, or a library which
it uses.
The consequences of a memory corruption bug often depend upon the
exact memory layout, or even the exact contents of uninitialised
memory. Sometimes it will cause problems, sometimes it won't.
It doesn't help that such bugs often fail to manifest if the program
is run under a debugger (colloquially referred to as a "Heisenbug", in
reference to the quantum mechanics principle that simply observing a
system can change its behaviour).
The funny is that the different results replace each other after each
attempt (I think I tried more than 6 times). One error and one success,
one error and one success...