Opened 10 years ago
Closed 10 years ago
#5351 closed defect (invalid)
GDAL fails with some PDF files
Reported by: | jolly47roger | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | default | Version: | |
Severity: | normal | Keywords: | |
Cc: |
Description
I have been trying to process some National Park maps to make GEOTIFF files from the GEOPDF.
With a number of them, GDAL Translate types the file size then a single '0' and Windows reports "GDAL_Translate has stopped working"
Here is one of several that fail : http://www.nps.gov/hfc/carto/PDF/ACADmap2.pdf
Version : GDAL 110 MSVC 2010 Win 64 12/01/2014
Attachments (1)
Change History (9)
by , 10 years ago
comment:1 by , 10 years ago
I cannot reproduce with Linux 64 bit / Poppler 0.24.1, nor with the 32 bit Windows build at http://www.gisinternals.com/sdk/PackageList.aspx?file=release-1600-gdal-mapserver.zip with Poppler 0.15.1 If it is not the case, can you try with one of the builds at http://www.gisinternals.com/sdk/ ?
follow-up: 3 comment:2 by , 10 years ago
I am using the download from GISInternals SDK . I will try a 32bit version tomorrow
comment:3 by , 10 years ago
Replying to jolly47roger:
I am using the download from GISInternals SDK . I will try a 32bit version tomorrow
Downloaded the 32bit version from GISInternals : 2014.01.14 "MSVC2010 (Win32) -stable" but still get the same failure.
comment:4 by , 10 years ago
And did you try the link I provided above to the -development version ? If this works for you, then it is an issue in the stable version fixed in the development version (but I don't recall recent fixes in the PDF driver). If this does not work, then it is something subtle since the same build would fail for you and not for me...
comment:5 by , 10 years ago
There is no GDAL core.msi in the development version (only a version with mapserver that needs IIS). I know of at least one other user - in the US - who has the same problem. I also tried "MSVC2010 (Win64) -development" which also fails
comment:6 by , 10 years ago
Just download http://www.gisinternals.com/sdk/PackageList.aspx?file=release-1600-gdal-mapserver.zip, unzip the file somewhere and run SDKShell.bat from it and you should be able to run gdal_translate. I have no win64 available to do tests on that platform.
comment:7 by , 10 years ago
I have done that : no change
"C:\Users\John\Downloads\release-1600-gdal-mapserver\ C:\Users\John\Downloads\release-1600-gdal-mapserver\ Setting environment for using the GDAL and MapServer tools. Hiding the OCI plugin library.
1 file(s) moved. 1 file(s) moved.
C:\Users\John\Downloads\release-1600-gdal-mapserver>gdal_translate.exe --config GDAL_PDF_DPI 250 --config GDAL_DATA "c:\program files\gdal\gdal-data" -of GTiff
-co compress=lzw "D:\mtest\jan14\ACADmap2.pdf" "C:\Users\John\AppData\Local\Tem
p\pdftemp.tif" Input file size is 5208, 4514 0 C:\Users\John\Downloads\release-1600-gdal-mapserver>"
comment:8 by , 10 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Version: | 1.10.0 |
The --config GDAL_PDF_DPI 250 makes the difference for me. Too bad you didn't mention it at the beginning. I could indeed reproduce a crash, but around 10% (but under wine, not native Windows, so that can account for the difference)
Debugging with Windows is just horrible, so I tried to reproduce on Linux in the closest conditions, and instead of using a recent Poppler version, I used Poppler 0.15.1, the same version used in gisinternals builds, and I can indeed see the following warnings with the Valgrind memory debugger:
0==13448== Invalid read of size 1 ==13448== at 0x71BD0A0: Splash::blitTransparent(SplashBitmap*, int, int, int, int, int, int) (Splash.cc:3230) ==13448== by 0x70DFDF3: SplashOutputDev::beginTransparencyGroup(GfxState*, double*, GfxColorSpace*, bool, bool, bool) (SplashOutputDev.cc:2945) ==13448== by 0x712A74E: Gfx::doForm1(Object*, Dict*, double*, double*, bool, bool, GfxColorSpace*, bool, bool, bool, Function*, GfxColor*) (Gfx.cc:4499) ==13448== by 0x713659D: Gfx::doForm(Object*) (Gfx.cc:4437) ==13448== by 0x7136AD4: Gfx::opXObject(Object*, int) (Gfx.cc:3939) ==13448== by 0x7124877: Gfx::go(bool) (Gfx.cc:711) ==13448== by 0x712A3A4: Gfx::display(Object*, bool) (Gfx.cc:678) ==13448== by 0x716FE93: Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, Catalog*, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) (Page.cc:482) ==13448== by 0x578D66B: PDFDataset::ReadPixels(int, int, int, int, int, int, int, unsigned char*) (pdfdataset.cpp:1059) ==13448== by 0x578DC41: PDFDataset::IRasterIO(GDALRWFlag, int, int, int, int, void*, int, int, GDALDataType, int, int*, int, int, int) (pdfdataset.cpp:1551) ==13448== by 0x59280DE: GDALProxyDataset::IRasterIO(GDALRWFlag, int, int, int, int, void*, int, int, GDALDataType, int, int*, int, int, int) (gdalproxydataset.cpp:57) ==13448== by 0x40814D: GDALMultiThreadedReaderDataset::IRasterIO(GDALRWFlag, int, int, int, int, void*, int, int, GDALDataType, int, int*, int, int, int) (gdal_translate.cpp:352) ==13448== Address 0x1b767843 is not stack'd, malloc'd or (recently) free'd
Those are defects in Poppler code itself, that are not found in later versions. They don't cause crash on Linux, but this is just by chance. So this doesn't seem a GDAL issue, but more a packaging consistency. I encourage you to file a ticket to https://github.com/gisinternals/buildsystem/issues/new .
Error displayed