[GRASSLIST:3088] segmentation fault with GDAL

GRASS GRASS user
,
1

Dear GrassList,
I am running linux binaries which include the GDAL
binaries and want to import a .jpg file. I keep
getting this segmentation fault-- I verified that
have enough memory on the system-- any other
suggestions?

Here is the message:

GRASS:/usr/local/share/grassdata/spearfish > r.in.gdal
-eo in=goodNavigation.jpg location=test out=goodNav
Segmentation fault

Thanks,
Stef

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/

2

On Sat, 3 Apr 2004, stef wrote:

Dear GrassList,
I am running linux binaries which include the GDAL
binaries and want to import a .jpg file. I keep
getting this segmentation fault-- I verified that
have enough memory on the system-- any other
suggestions?

Your binaries are probably broken. Where did you get them? You will need
to obtain working ones or compile yourself. Probably easier to do something
like convert the JPEG into a TIFF using some other image processing
software and then use r.in.tiff.

Paul

3

Hi Paul,
Thanks for your reply. I got the GDAL binaries from
the linked grass site for GDAL.
I did convert the jpg to a tiff via-a-vis Photoshop
and then read the file into grass. I get the
following:

r.in.tiff complexCorridor

{all the flags etc}
then three maps get placed into /cell
complexCorridor.b
complexCorridor.g
complexCorridor.r
I then opened a monitor to read the raster map of
complex corridor in and I get this message: "raster
map not found in current mapset"
I then ran r.support -r and get the following "raster
map not found in current mapset"
Any other suggestions?
Thanks,
Stef

--- Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:

On Sat, 3 Apr 2004, stef wrote:

> Dear GrassList,
> I am running linux binaries which include the GDAL
> binaries and want to import a .jpg file. I keep
> getting this segmentation fault-- I verified that
> have enough memory on the system-- any other
> suggestions?

Your binaries are probably broken. Where did you get
them? You will need
to obtain working ones or compile yourself. Probably
easier to do something
like convert the JPEG into a TIFF using some other
image processing
software and then use r.in.tiff.

Paul

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/

4

--- Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:

On Sat, 3 Apr 2004, stef wrote:

> Dear GrassList,
> I am running linux binaries which include the GDAL
> binaries and want to import a .jpg file. I keep
> getting this segmentation fault-- I verified that
> have enough memory on the system-- any other
> suggestions?

Your binaries are probably broken. Where did you get
them? You will need
to obtain working ones or compile yourself. Probably
easier to do something
like convert the JPEG into a TIFF using some other
image processing
software and then use r.in.tiff.

Paul

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/

5

On Sun, 4 Apr 2004, stef wrote:

Hi Paul,
Thanks for your reply. I got the GDAL binaries from
the linked grass site for GDAL.

I meant the GRASS binaries: which version and where you downloaded them
from? I notice the 5.0.3 Linux binaries on the website are quite recent so
if the fault occured with them then it is possible that whoever created
them didn't use the --with-gdal configure option and they should be
re-done.

then three maps get placed into /cell
complexCorridor.b
complexCorridor.g
complexCorridor.r
I then opened a monitor to read the raster map of
complex corridor in and I get this message: "raster
map not found in current mapset"

There are 3 raster maps, one for each colour band. Display them with d.rgb

6

On Sun, 4 Apr 2004, Paul Kelly wrote:

On Sun, 4 Apr 2004, stef wrote:

> Hi Paul,
> Thanks for your reply. I got the GDAL binaries from
> the linked grass site for GDAL.

I meant the GRASS binaries: which version and where you downloaded them
from? I notice the 5.0.3 Linux binaries on the website are quite recent so
if the fault occured with them then it is possible that whoever created
them didn't use the --with-gdal configure option and they should be
re-done.

Not that this helps much with the current problem (maybe), but I'm pretty
sure that I made those binaries. I just checked, and (1) I used the
--with-gdal switch, (2) r.in.gdal is working on my machine, and (3) I used
GDAL 1.2.0 (CVS) as of March 5.

However, this is the first external feedback on those binaries I've
noticed, so they're relatively untested - and saying that "they work on my
machine" is not saying a lot.

Would it cause problems if the binary GDAL build involved is a different
version than the one I built with?

Scott Mitchell
smitch@mac.com

7

On Mon, 5 Apr 2004, Scott W Mitchell wrote:

> I meant the GRASS binaries: which version and where you downloaded them
> from? I notice the 5.0.3 Linux binaries on the website are quite recent so
> if the fault occured with them then it is possible that whoever created
> them didn't use the --with-gdal configure option and they should be
> re-done.

Not that this helps much with the current problem (maybe), but I'm pretty
sure that I made those binaries. I just checked, and (1) I used the
--with-gdal switch, (2) r.in.gdal is working on my machine, and (3) I used
GDAL 1.2.0 (CVS) as of March 5.

Then there is a good chance that the other recently-found bug in r.in.gdal
will have been causing the problem. 5.0.3 still contains this bug, but I
copied the fix to the release branch yesterday:
http://grass.itc.it/pipermail/grass-commit/2004-April/011397.html

As the bug was something to do with the unit name, it is perhaps more
likely to occur on a non-georeferenced file, like a JPEG. Maybe this was
the problem... did you try it with a JPEG image on your machine.

If that was the problem, we could always do new binaries using the latest
release branch code, but then it wouldn't be true 5.0.3.

Really shouldn't bother with 5.0.3 any more though :slight_smile:

Would it cause problems if the binary GDAL build involved is a different
version than the one I built with?

But did you not include the gdal library in the GRASS binary distribution,
so it is the same one as you compiled with? I suppose if there is more
than one GDAL installed on the system the potential for that is there
though.

Paul

8

Actually, my test file was a gif, but still no spatial ref, so I assume that's the same idea. I did include the 1.2.0 GDAL lib in the binary distribution, soft linking to it with the generic library name (libgdal.so.1 in this case).

Soo... not clear to me what that means - that the bug that you fixed in the release branch IS the culprit here, so that the solution would be "non-5.0.3?"

I agree that there's limited utility in worrying too much about 5.0.3, but am happy to try a simple fix if there is one.

On 5-Apr-04, at 13:15, Paul Kelly wrote:

On Mon, 5 Apr 2004, Scott W Mitchell wrote:

I meant the GRASS binaries: which version and where you downloaded them
from? I notice the 5.0.3 Linux binaries on the website are quite recent so
if the fault occured with them then it is possible that whoever created
them didn't use the --with-gdal configure option and they should be
re-done.

Not that this helps much with the current problem (maybe), but I'm pretty
sure that I made those binaries. I just checked, and (1) I used the
--with-gdal switch, (2) r.in.gdal is working on my machine, and (3) I used
GDAL 1.2.0 (CVS) as of March 5.

Then there is a good chance that the other recently-found bug in r.in.gdal
will have been causing the problem. 5.0.3 still contains this bug, but I
copied the fix to the release branch yesterday:
http://grass.itc.it/pipermail/grass-commit/2004-April/011397.html

As the bug was something to do with the unit name, it is perhaps more
likely to occur on a non-georeferenced file, like a JPEG. Maybe this was
the problem... did you try it with a JPEG image on your machine.

If that was the problem, we could always do new binaries using the latest
release branch code, but then it wouldn't be true 5.0.3.

Really shouldn't bother with 5.0.3 any more though :slight_smile:

Would it cause problems if the binary GDAL build involved is a different
version than the one I built with?

But did you not include the gdal library in the GRASS binary distribution,
so it is the same one as you compiled with? I suppose if there is more
than one GDAL installed on the system the potential for that is there
though.

Paul

------
Scott W. Mitchell Scott_Mitchell@carleton.ca
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building (Office A209)
1125 Colonel By Drive, Ottawa, ON Canada K1S 5B6
+1-613-520-2600 ext 2695 Fax: 1-613-520-4301