PDFium driver crashes with segfault

[shot2]

System: fresh Ubuntu 17.04 x86_64, gcc 6.3.0, GDAL 2.2.0 compiled from source including static PDFium library (Rouault's build-lin.sh script, minus '-fVisibility=hidden')

Issue: gdal compiles successfully against the PDFium driver (confirmed when running gdalinfo --format PDF); however running the following commands result in a crash:

./gdal_translate -of PDF ~/sample.tif ~/sample.pdf --config CPL_DEBUG ON
GDAL: GDALOpen(/home/admin/sample.tif, this=0x55784c32fcc0) succeeds as GTiff.
Input file size is 1335, 1597
0OGRCT: PROJ >= 4.8.0 features enabled
OGRCT: Using locale-safe proj version
OGRCT: Source: +proj=longlat +datum=WGS84 +no_defs
OGRCT: Target: +proj=longlat +datum=WGS84 +no_defs
GDAL: GDAL_CACHEMAX = 49 MB
...10...20...30...40...50...60...70...80...90...100 - done.
Segmentation fault (core dumped)

N.B. The resulting GeoPDF file is still correctly created, it performs as intended under e.g. Adobe Reader.

./gdalinfo ~/sample.pdf --config CPL_DEBUG ON
Segmentation fault (core dumped)

Other: similar issue described by another user on gdal-dev's mailing-list ( ​https://lists.osgeo.org/pipermail/gdal-dev/2017-May/046631.html )

As a sidenote, everything works as expected when compiling/linking GDAL 2.2.0 against libpoppler; it looks definitely like a problem with PDFium reading/reopening datasets.

[Even Rouault]

Can you install valgrind and run "valgrind ./gdalinfo ~/sample.pdf" ?

[shot2]

Results from valgrind ./gdalinfo ~/sample.pdf (PDFium compiled as plugin, gdal_PDF.so):

$ valgrind ./gdalinfo ~/sample.pdf
==1025== Memcheck, a memory error detector
==1025== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1025== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==1025== Command: ./gdalinfo /home/admin/sample.pdf
==1025==
==1025== Invalid read of size 8
==1025==    at 0x1D3B388B: CFX_Plex::FreeDataChain() (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x1D3B258F: CFX_MapPtrToPtr::RemoveAll() (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x1D26C1C9: CPDF_Parser::CloseParser(int) (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x1D27857C: CPDF_Parser::StartParse(IFX_FileRead*, int, int) (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x1D218A4B: FPDF_LoadCustomDocument (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x1D1F32B2: PDFDataset::Open(GDALOpenInfo*) (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x54D2C1F: GDALOpenEx (in /var/tmp/dmz/install/usr/local/lib/libgdal.so.20.2.0)
==1025==    by 0x109051: ??? (in /var/tmp/dmz/install/usr/local/bin/gdalinfo)
==1025==    by 0x4E5A3F0: (below main) (libc-start.c:291)
==1025==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1025==
==1025==
==1025== Process terminating with default action of signal 11 (SIGSEGV)
==1025==  Access not within mapped region at address 0x0
==1025==    at 0x1D3B388B: CFX_Plex::FreeDataChain() (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x1D3B258F: CFX_MapPtrToPtr::RemoveAll() (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x1D26C1C9: CPDF_Parser::CloseParser(int) (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x1D27857C: CPDF_Parser::StartParse(IFX_FileRead*, int, int) (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x1D218A4B: FPDF_LoadCustomDocument (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x1D1F32B2: PDFDataset::Open(GDALOpenInfo*) (in /var/tmp/dmz/install/usr/local/lib/gdalplugins/gdal_PDF.so)
==1025==    by 0x54D2C1F: GDALOpenEx (in /var/tmp/dmz/install/usr/local/lib/libgdal.so.20.2.0)
==1025==    by 0x109051: ??? (in /var/tmp/dmz/install/usr/local/bin/gdalinfo)
==1025==    by 0x4E5A3F0: (below main) (libc-start.c:291)
==1025==  If you believe this happened as a result of a stack
==1025==  overflow in your program's main thread (unlikely but
==1025==  possible), you can try to increase the size of the
==1025==  main thread stack using the --main-stacksize= flag.
==1025==  The main thread stack size used in this run was 8388608.
==1025==
==1025== HEAP SUMMARY:
==1025==     in use at exit: 663,570 bytes in 4,243 blocks
==1025==   total heap usage: 5,441 allocs, 1,198 frees, 1,035,923 bytes allocated
==1025==
==1025== LEAK SUMMARY:
==1025==    definitely lost: 0 bytes in 0 blocks
==1025==    indirectly lost: 0 bytes in 0 blocks
==1025==      possibly lost: 0 bytes in 0 blocks
==1025==    still reachable: 663,570 bytes in 4,243 blocks
==1025==         suppressed: 0 bytes in 0 blocks
==1025== Rerun with --leak-check=full to see details of leaked memory
==1025==
==1025== For counts of detected and suppressed errors, rerun with: -v
==1025== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

[Even Rouault]

Looks like an issue in PDFium itself. Perhaps you should try with a more recent version of PDFium that the one I forked at the time.

[shot2]

Problem with outdated PDFium