Opened 11 years ago
Closed 10 years ago
#2442 closed defect (worksforme)
[raster] Segfault when doing raster2pgsql
Reported by: | thesteve0 | Owned by: | dustymugs |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.2.0 |
Component: | raster | Version: | 2.0.x |
Keywords: | Cc: |
Description
When trying to run raster2pgsql on Fedora 19 to process a geotiff I get a segfault
psql (PostgreSQL) 9.2.4 GDAL 1.9.2, released 2012/10/08
The file I am using is over 100 megs so I don't think I should attach it to the ticket.
(gdb) run -s 3309 -t 100x100 -I -M -l 4 IR_R_G.tif public.erdastest > gdb.sql Starting program: /usr/bin/raster2pgsql -s 3309 -t 100x100 -I -M -l 4 IR_R_G.tif public.erdastest > gdb.sql [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Processing 1/1: IR_R_G.tif
Program received signal SIGSEGV, Segmentation fault. 0x0000003d7667c44d in malloc_consolidate () from /usr/lib64/libc.so.6 (gdb) bt #0 0x0000003d7667c44d in malloc_consolidate () from /usr/lib64/libc.so.6 #1 0x0000003d7667cfd6 in _int_free () from /usr/lib64/libc.so.6 #2 0x0000003a0c418278 in gtCSVDeaccess () from /usr/lib64/libgeotiff.so.1.2 #3 0x0000003a0c4182c9 in gtCSVDeaccess () from /usr/lib64/libgeotiff.so.1.2 #4 0x0000003a0934a8c2 in GDALDriver::~GDALDriver() ()
from /usr/lib64/libgdal.so.1
#5 0x0000003a0934a8f9 in GDALDriver::~GDALDriver() ()
from /usr/lib64/libgdal.so.1
#6 0x0000003a0934cac0 in GDALDriverManager::~GDALDriverManager() ()
from /usr/lib64/libgdal.so.1
#7 0x0000003a0934caf9 in GDALDriverManager::~GDALDriverManager() ()
from /usr/lib64/libgdal.so.1
#8 0x0000003a090e37ce in GDALDestroy() () from /usr/lib64/libgdal.so.1 #9 0x0000003d75e0fb6a in _dl_fini () from /lib64/ld-linux-x86-64.so.2 #10 0x0000003d766392a9 in run_exit_handlers () from /usr/lib64/libc.so.6 #11 0x0000003d766392f5 in exit () from /usr/lib64/libc.so.6 #12 0x0000003d76621b7c in libc_start_main () from /usr/lib64/libc.so.6 #13 0x00000000004053a5 in _start ()
Change History (17)
comment:2 by , 11 years ago
Component: | postgis → raster |
---|---|
Milestone: | PostGIS 2.1.0 → PostGIS 2.1.1 |
Owner: | changed from | to
Summary: | [rasters] Segfault when doing raster2pgsql → [raster] Segfault when doing raster2pgsql |
Steve, You have a download link to the file?
comment:3 by , 11 years ago
From the backtrace, the problem appears to be in GDAL or the external GeoTIFF library. Is it possible to try a GDAL built with its internal GeoTIFF library?
comment:4 by , 11 years ago
Here is a link to the file https://dl.dropboxusercontent.com/u/1301514/IR_R_G.tif
I can't. I am just trying to use the packaged version that comes with Fedora 19. Let me know how you would like to proceed. Thanks Steve
comment:5 by , 11 years ago
Just tested PostGIS 2.0 and 2.1 using GDAL trunk built with internal GeoTIFF support. So, the problem definitely is not in PostGIS.
comment:6 by , 11 years ago
Ok so then it is a postgis packaging/GDAL packaging issue on Fedora right? If so how do you think I should communicate the problem to them?
comment:7 by , 11 years ago
I can't say that it is a fedora packaging issue. Can you try running gdalinfo on the raster file and see if it has issues?
comment:8 by , 11 years ago
Works fine
[spousty@localhost tmp]$ gdalinfo IR_R_G.tif Driver: GTiff/GeoTIFF Files: IR_R_G.tif Size is 7794, 7260 Coordinate System is: PROJCS["unnamed", GEOGCS["NAD83", DATUM["North_American_Datum_1983", SPHEROID["GRS 1980",6378137,298.2572221010002, AUTHORITY["EPSG","7019"]], AUTHORITY["EPSG","6269"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4269"]], PROJECTION["Albers_Conic_Equal_Area"], PARAMETER["standard_parallel_1",34], PARAMETER["standard_parallel_2",40.5], PARAMETER["latitude_of_center",0], PARAMETER["longitude_of_center",-120], PARAMETER["false_easting",0], PARAMETER["false_northing",-4000000], UNIT["metre",1, AUTHORITY["EPSG","9001"]]] Origin = (-311711.607355843007099,51188.279698056103371) Pixel Size = (30.000000000000000,-30.000000000000000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( -311711.607, 51188.280) (123d34'31.75"W, 38d25'26.25"N) Lower Left ( -311711.607, -166611.720) (123d29' 1.42"W, 36d27'57.42"N) Upper Right ( -77891.607, 51188.280) (120d53'37.87"W, 38d28'24.73"N) Lower Right ( -77891.607, -166611.720) (120d52'15.22"W, 36d30'51.36"N) Center ( -194801.607, -57711.720) (122d12'21.77"W, 37d28'36.59"N) Band 1 Block=7794x1 Type=Byte, ColorInterp=Red Band 2 Block=7794x1 Type=Byte, ColorInterp=Green Band 3 Block=7794x1 Type=Byte, ColorInterp=Blue
comment:10 by , 11 years ago
Works great as well. It is something about the -l that is making things go wonky
comment:11 by , 11 years ago
Ah. That would explain it. -l makes use of a VRT on top of the source raster to generate overviews. Can you create a VRT on that raster with gdalbuildvrt and test gdalinfo on that generated VRT?
comment:12 by , 11 years ago
Can you explain (or just paste the parameters) on how you would use it?
comment:13 by , 11 years ago
I've found that some raster format drivers have issues with be wrapped with a VRT. These issues haven't happened consistently but they have always been related to VRTs.
Try something like the following…
gdalbuildvrt -tr 120 120 test.vrt IR_R_G.tif gdalinfo -stats test.vrt
Based upon how that gdalinfo returns, I'll do some testing to see if raster2pgsql's aggressive use of GDALClose() is conflicting with VRT's handling of GDAL datasets.
comment:14 by , 11 years ago
Status: | new → assigned |
---|
comment:15 by , 11 years ago
Milestone: | PostGIS 2.1.1 → PostGIS 2.2.0 |
---|
comment:17 by , 10 years ago
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
Closing due lack of activity and that the problem was diagnosed to a driver/VRT interaction issue.