GDAL fails with some PDF files

[jolly47roger]

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

[jolly47roger]

Error displayed

[Even Rouault]

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/ ?

[jolly47roger]

I am using the download from GISInternals SDK . I will try a 32bit version tomorrow

[jolly47roger]

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.

[Even Rouault]

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...

[jolly47roger]

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

[Even Rouault]

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.

[jolly47roger]

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>"

[Even Rouault]

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 .