Opened 9 years ago

Closed 9 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:


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 :

Version : GDAL 110 MSVC 2010 Win 64 12/01/2014

Attachments (1)

gdal.png (52.1 KB ) - added by jolly47roger 9 years ago.
Error displayed

Download all attachments as: .zip

Change History (9)

by jolly47roger, 9 years ago

Attachment: gdal.png added

Error displayed

comment:1 by Even Rouault, 9 years ago

I cannot reproduce with Linux 64 bit / Poppler 0.24.1, nor with the 32 bit Windows build at with Poppler 0.15.1 If it is not the case, can you try with one of the builds at ?

comment:2 by jolly47roger, 9 years ago

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

in reply to:  2 comment:3 by jolly47roger, 9 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 Even Rouault, 9 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 jolly47roger, 9 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 Even Rouault, 9 years ago

Just download, 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 jolly47roger, 9 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 Even Rouault, 9 years ago

Resolution: invalid
Status: newclosed
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) (
==13448==    by 0x70DFDF3: SplashOutputDev::beginTransparencyGroup(GfxState*, double*, GfxColorSpace*, bool, bool, bool) (
==13448==    by 0x712A74E: Gfx::doForm1(Object*, Dict*, double*, double*, bool, bool, GfxColorSpace*, bool, bool, bool, Function*, GfxColor*) (
==13448==    by 0x713659D: Gfx::doForm(Object*) (
==13448==    by 0x7136AD4: Gfx::opXObject(Object*, int) (
==13448==    by 0x7124877: Gfx::go(bool) (
==13448==    by 0x712A3A4: Gfx::display(Object*, bool) (
==13448==    by 0x716FE93: Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, Catalog*, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) (
==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 .

Note: See TracTickets for help on using tickets.