Opened 18 years ago

Closed 16 years ago

Last modified 15 years ago

#348 closed bug (fixed)

Crash on OSX when loading GeoTIFF

Reported by: anonymous Owned by: telwertowski
Priority: critical: causes crash or data corruption Milestone:
Component: Rasters Version: 0.9.1
Keywords: gdal geotiff Cc:
Must Fix for Release: Yes Platform: OS X
Platform Version: 10.4.8 Awaiting user input: no

Description

Maybe it's just out of memory, but I get a "Bus Error" when trying to load a large GeoTIFF. [I guess that's Mac for SegFault]

Same with 5 different machines with the same setup.

PPC MiniMac with 512mb RAM. (but out of memory shouldn't cause a bus error?) I'll see if I can try a smaller GeoTIFF.

It also crashed sometimes when loading a large shapefile. (but then worked on restart)

the same file loaded fine in 0.7.4 on Windows.

file size is 120361625 (115M)

$ gdalinfo Driver: GTiff/GeoTIFF Size is 10720, 12320 Coordinate System is: PROJCS["New Zealand Map Grid",

GEOGCS["international",

DATUM["New_Zealand_Geodetic_Datum_1949",

SPHEROID["International 1924",6378388,297.000000000005,

AUTHORITY["EPSG","7022"]],

AUTHORITY["EPSG","6272"]],

PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]],

PROJECTIONNew_Zealand_Map_Grid, PARAMETER["latitude_of_origin",44058.00790893473], PARAMETER["central_meridian",-1.957775357725225], PARAMETER["false_easting",8.166501998822767], PARAMETER["false_northing",44058], UNIT["metre",1,

AUTHORITY["EPSG","9001"]]]

Origin = (2309200.000000,5502100.000000) Pixel Size = (2.50000000,-2.50000000) Metadata:

AREA_OR_POINT=Area

Corner Coordinates: Upper Left ( 2309200.000, 5502100.000) (170d25'28.64"E, 45d39'43.78"S) Lower Left ( 2309200.000, 5471300.000) (170d24'44.63"E, 45d56'20.82"S) Upper Right ( 2336000.000, 5502100.000) (170d46'6.08"E, 45d40'8.69"S) Lower Right ( 2336000.000, 5471300.000) (170d45'28.13"E, 45d56'45.79"S) Center ( 2322600.000, 5486700.000) (170d35'26.88"E, 45d48'15.25"S) Band 1 Block=10720x1 Type=Int16, ColorInterp=Gray

NoData Value=0

Metadata:

COLOR_TABLE_RULES_COUNT=1 COLOR_TABLE_RULE_RGB_0=0.000000e+00 2.550000e+02 0 0 0 255 255 255

Attachments (4)

nz25_NZMG_gdal_IntPix_Pacbit_crop.tif (82.2 KB ) - added by hamish_nospam@… 17 years ago.
GeoTiff which causes Bus Error on OSX
qgis_crash_osx.txt (23.1 KB ) - added by hamish_nospam@… 17 years ago.
core dump (OSX report text file)
qgis_crash_osx_31Jan2007.txt (26.6 KB ) - added by hamish_nospam@… 17 years ago.
core dump (OSX report text file) from 0.8.0 release
qgis_crash_osx_11Feb2008.txt (27.7 KB ) - added by hamish 16 years ago.
core dump (OSX report text file) from 0.9.1 release

Download all attachments as: .zip

Change History (31)

comment:1 by anonymous, 18 years ago

(exported from GRASS)

comment:2 by rblazek, 17 years ago

Priority: majorcritical

comment:3 by gsherman, 17 years ago

Must Fix for Release: Yes

comment:4 by g_j_m, 17 years ago

This may have been the same problem as ticket #248, which was recently fixed (r6072). Can you try it again with the latest version of qgis?

comment:5 by gsherman, 17 years ago

Without further input or sample data we can't fix this.

comment:6 by hamish_nospam@…, 17 years ago

Hi, sorry for the delay getting back to you, I hadn't seen the reply.

I am thinking now it has more to do with the export compression options than filesize. I will export using various methods and try and pin down what's failing. I can only test with the available OSX binaries.

thanks, Hamish

comment:7 by hamish_nospam@…, 17 years ago

Hi, had a chance to do some more testing.

It fails on a Mac with a GeoTIFF created with gdal_translate. (DebianGIS gdal package version: 1.3.1-0.dgis.stable.2)

tested with:

PC: 0.8pre3-cvs binary posted by Tim December 10th. Mac: 0.8pre2 binary download linked from .8p2 news item

I tried a number of different export options.

Worked (PC+Mac): GRASS's r.out.tiff C module.

compress=none,defalte*,lzw,packbit

  • deflate failed cleanly on the Mac with "deflate support not configured" error printed to stderr (ran from Terminal). I assume this has to do with the GDAL configure options in the supplied binary. No error window poped up though, just left with a blank screen. Another wierdness on the Mac: the wristwatch hourglass mouse cursor stayed on, always.

Failed (Mac only): export using GRASS 6.2's r.out.gdal, which is just a frontend bash script for gdal_translate with the GDAL/GRASS plugin. compress=none,defalte,lzw,packbit; INTERLEAVE=PIXEL. also tried compress=packbit,INTERLEAVE=BAND with no luck. Worked fine on the PC (0.7.4 and 0.8pre3_Tim_10Dec)

I'll try and upload a crop of the GeoTIFF here.

Hamish

comment:8 by anonymous, 17 years ago

link to test data (84kb): (I couldn't figure out how to upload a file to the tracker)

http://bambi.otago.ac.nz/hamish/grass/qgis/nz25_NZMG_gdal_IntPix_Pacbit_crop.tif

create command in GRASS 6.2:

r.out.gdal in=nz25 type=Byte createopt="INTERLEAVE=PIXEL,TFW=YES,COMPRESS=PACKBITS" out=nz25_NZMG_gdal_IntPix_Pacbits_crop.tif -r

comment:9 by hamish_nospam@…, 17 years ago

Summary: Crash on OSX when loading a large GeoTIFFCrash on OSX when loading GeoTIFF

by hamish_nospam@…, 17 years ago

GeoTiff which causes Bus Error on OSX

by hamish_nospam@…, 17 years ago

Attachment: qgis_crash_osx.txt added

core dump (OSX report text file)

comment:10 by anonymous, 17 years ago

The crash report suggests that the problem is with gdal, not qgis. Your comments also suggest that you're using gdal 1.3.1? There is a later version available that may fix this problem (v1.3.2). Please try that if possible.

comment:11 by gsherman, 17 years ago

Resolution: fixed
Status: newclosed

The test file works fine for me with latest OS X build, using GDAL 1.31 on a G4 powerbook with 512Mb ram.

I'm closing this ticket but it can be reopened if the problem persists for you in the upcoming preview 3 release.

comment:12 by anonymous, 17 years ago

Ok, I will retry when OSX binaries for pre3 show up.

Hamish

comment:13 by anonymous, 17 years ago

The crash report suggests that the problem is with gdal, not qgis. Your comments also suggest that you're using gdal 1.3.1? There is a later version available that may fix this problem (v1.3.2). Please try that if possible.

That is I used GDAL 1.3.1 on Debian/Stable to make the GeoTIFF. [I have been waiting for the DebianGIS project to release a GDAL 1.3.2 package for Sarge, but I don't think this is going to happen, so I wait for the next full Debian release (soonish).]

I have just now tried re-exporting the GeoTIFF using GDAL 1.3.2 by loading the GeoTIFF into GRASS 6.2.1 on the same Mac (no problems), then re-exporting using r.out.gdal (r.out.gdal is just a script front-end to gdal_translate)). Same Bus Error with the new copy.

The Mac where this fails has GDAL 1.3.2 existing both in the GRASS Frameworks[*] and QGIS 0.8pre2's libgdal1.dynlib 1.3.2.0.

[*] version 17-Dec-2006

Hamish

comment:14 by hamish_nospam@…, 17 years ago

Keywords: gdal geotiff added
Resolution: fixed
Status: closedreopened

Hi,

it still crashes with the 0.8.0 release, uploading latest crash info as bug attachment and reopening the bug.

(using Tom Elwertowski's binaries; William's GRASS binaries + frameworks installed on the same machine)

thanks, Hamish

comment:15 by anonymous, 17 years ago

Milestone: Version 0.8 ReleaseVersion 0.8.1 Release

by hamish_nospam@…, 17 years ago

core dump (OSX report text file) from 0.8.0 release

comment:16 by timlinux, 17 years ago

Milestone: Version 0.8.1 ReleaseVersion 0.8.2 Release

comment:17 by warmerdam, 16 years ago

Awaiting user input: unset

I have reviewed the traceback and this section:

1   libjasper-1.701.1.dylib     0x02507634 GTIFGetGCSInfo + 116
2   libgdal.1.dylib             0x01bcd550 GTIFGetOGISDefn + 352

suggests that the build uses the jasper library which has (apparently) a copy of libgeotiff embedded but (presumably) a somewhat different version than is embeded or expected to be used by GDAL. This results in a crash when something is where it is expected. Basically it is very bad karma to have two versions of something like libgeotiff in an application and can result in suprising calls between the two binary incompatible instances.

The solution (IMHO) is that libjasper should be linked against a system libgeotiff instead of using an embedded copy. I don't see this as a QGIS bug - it is a particular issue with the way the packages QGIS depends on have been built. My suggestion is that this bug report be closed, possibly after referring to whoever is behind the build (William?)

comment:18 by timlinux, 16 years ago

Resolution: wontfix
Status: reopenedclosed

As suggested, I have sent William an email asking him to take note of this ticket, and am closing this ticket.

comment:19 by kyngchaos, 16 years ago

Hmm, works on my recent 0.9.1 and 0.9.2 binaries. They use GDAL 1.5, libtiff 4 SVN, geotiff 1.2.4. The 0.8.x referred to are probably Tom's all-in-one, since my Qgis binaries use my frameworks. I don't have an extra Mac handy to test my old 0.8 binaries on this, which use GDAL 1.4.

libjasper doesn't link to geotiff or libtiff, as far as I know.

I do remember (kinda hazy, though I reported it) some libtiff crashes when saving with some compressions, but not opening. That was around the GDAL 1.3.1 time - libtiff 3.7-3.8. It was slowly fixed and is fine in 3.9/4.0.

... just a few thoughts. All I can suggest is upgrade to Qgis 0.9.x with latest libraries/frameworks.

comment:20 by hamish, 16 years ago

William:

Hmm, works on my recent 0.9.1 and 0.9.2 binaries.

...

All I can suggest is upgrade to Qgis 0.9.x with latest libraries/frameworks.

Ok, I will try that and report back.

thanks, Hamish

comment:21 by hamish, 16 years ago

Hi,

I have just installed 0.9.1 from

http://download.osgeo.org/qgis/mac/qgis-0.9.1.dmg.gz

and it still crashes. :-(

I am not sure if this package is William derived or not, or if that package is all-in-one and includes new frameworks or is somehow depending on what it has already found on the machine.

Also on the same machine is an older copy of GRASS 6.2.1 & William's "all frameworks" from whenever that was installed. I see: Library/Frameworks/GDAL.framework/Versions/1.3

New crash log attached. The libjasper part is the same as quoted by Frank.

thanks, Hamish

by hamish, 16 years ago

core dump (OSX report text file) from 0.9.1 release

in reply to:  21 comment:22 by kyngchaos, 16 years ago

Replying to hamish:

I have just installed 0.9.1 from

http://download.osgeo.org/qgis/mac/qgis-0.9.1.dmg.gz

and it still crashes. :-(

I am not sure if this package is William derived or not, or if that package is all-in-one and includes new frameworks or is somehow depending on what it has already found on the machine.

This is Tom's (Elertowski) all-in-one. GDAL is bundled inside the app as a Unix library, and any installed GDAL framework or lbrary will be ignored. I don't know which version of GDAL he used.

comment:23 by telwertowski, 16 years ago

Resolution: wontfix
Status: closedreopened

Frank appears to have identified the problem. I had not realized until now that a copy of geotiff is embedded in the jasper lib used by all recent QGIS/Mac all-in-one builds.

In July 2006, I was informed that I was using an obsolete version of jasper and should use one from http://www.dimin.net/software/geojasper/. As a result of Frank's comment, I now see it contains embedded geotiff code with no option to configure as internal or external.

I am switching to the jasper distribution provided by Frank on the GDAL site. I suspect this will work. I am able to open the supplied tif file using William's UnixImageIO framework. The jasper distribution version William uses matches Frank's distribution s I suspect that when I switch and rebuild (which I won't get to for a day or two), the problem will be fixed.

comment:24 by telwertowski, 16 years ago

Owner: changed from timlinux to telwertowski
Status: reopenednew

comment:25 by hamish, 16 years ago

Version: 0.80.9.1

Just to report:

William's 0.9.1 Tiger binaries + latest frameworks fixes this for me.

I await Tom's new binaries, I'll test them when they arrive and then we can put this puppy to sleep.

Hamish

comment:26 by hamish, 16 years ago

Resolution: fixed
Status: newclosed

I have now tested Tom's brand new qgis-0.9.2rc1.dmg.gz.

Success!

good stuff guys, thanks. Closing the bug.

Hamish

comment:27 by (none), 15 years ago

Milestone: Version 0.9.2

Milestone Version 0.9.2 deleted

Note: See TracTickets for help on using tickets.