On 11.02.2017 00:33, Dennis Jenkins wrote:
> Has anyone attempted to analyze this issue using valgrind? (I have
> not yet). It smells like heap or stack corruption to me.
I've tracked it down: public podofo headers contain:
base/PdfCompilerCompat.h
#if (defined(_MSC_VER) && _MSC_VER < 1900) || (!defined(_MSC_VER) &&
__cplusplus < 201103)
#define PODOFO_ENUM_UINT8
#else
#define PODOFO_ENUM_UINT8 : uint8_t
#endif
base/PdfDefines.h: enum EPdfDataType PODOFO_ENUM_UINT8
base/PdfVariant.h: EPdfDataType m_eDataType;
mutable bool m_bDelayedLoadDone;
The podofo CMakeLists.txt adds -std=c++98 to the compile flags. If the
application is built with -std=c++11 (which is default for GCC6+) or
newer, it might allocate a differently sized than the EPdfDataType than
the library, and this leads to undefined behaviour (indeed,
m_bDelayedLoadDone is placed immediately after m_eDataType in
PdfVariant, which explains why it is affected by the undefined behaviour).
So rather than just removing -std=c++98 from the CMakeLists, the code
must be changed to ensure the size of the enum is always the same
regardless of the language standard one is using.
Sandro
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Podofo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users
