I am experiencing a 'segmentation fault' error when attempting to
convert a 220 point site file to raster using s.to.rast . The file was
created in v.digit, and edited in AbiWord and vi. It works fine as a
sites file (d.siter, d.sites etc) but when I try to convert it to a
raster file, the 'segmentation fault' error appears and the operation
terminates. The same file converts successfully to raster using
s.surf.rst; however I would like a simple raster map showing just the
sites also. Any ideas on what is causing this problem, and more
fundamentally -- what is a 'segmentation fault'?
I am using an OpenOSX installation of GRASS 5.0.0 running on MacOSX
10.2.4
No. There are two common approaches to finding out the cause. One is
trial-and-error (i.e. looking for specific factors which might cause
the problem). The other is to use a debugger.
One issue to consider when creating or editing text files on a Mac is
that historically the Mac has used CR (carriage return, ASCII code 13)
as the end-of-line character, while Unix (and hence GRASS) uses LF
(line feed, ASCII code 10). Text files which look correct in a text
editor may not be interpreted correctly by other problems.
You can convert CR to LF using:
tr '\r' '\n' < oldfile > newfile
and more fundamentally -- what is a 'segmentation fault'?
A segmentation fault corresponds to an invalid memory access; e.g.
reading from a non-existent memory location, or writing to a read-only
memory location.
No. There are two common approaches to finding out the cause. One is
trial-and-error (i.e. looking for specific factors which might cause
the problem). The other is to use a debugger.
I was afraid it might come down to that. Is it significant that
recently there have been quite a number of requests for assistance/
comments on segfaults -- even today (see 5990), 5955 on April 3 and 5889
on March 27 -- in relation to the use of r.to.rast?
One issue to consider when creating or editing text files on a Mac is
that historically the Mac has used CR (carriage return, ASCII code 13)
as the end-of-line character, while Unix (and hence GRASS) uses LF
(line feed, ASCII code 10). Text files which look correct in a text
editor may not be interpreted correctly by other problems.
You can convert CR to LF using:
tr '\r' '\n' < oldfile > newfile
Thanks for the conversion -- I have previously used BBedit's Mac to
Unix conversion, but that is cumbersome. In this case I had studiously
tried to avoid Mac cr's (using v.digit generated files edited in vi) and
the fact that r.surf.rst executed successfully suggests this may not be
the problem.