Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On Fri, 2017-02-17 at 17:24 +, Mark Rogers wrote: > The only changes needed after reverting are Hi, I did something like that and as it works fine here I also committed it as revision 1825: http://sourceforge.net/p/podofo/code/1825 I also committed a change which stops forcing c++98 standard for gcc compiler. There should not be any reason to do it only there, but not elsewhere. It's revision 1826: http://sourceforge.net/p/podofo/code/1826 It causes, for me and gcc 6.2.1 to claim a warning about an exception being thrown in PoDoFo::PdfPainter::~PdfPainter(), about which we spoke in a not so distant past. Bye, zyx -- http://www.litePDF.cz i...@litepdf.cz -- 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
I think the best solution is reverting then using pdf_unt8 to store the enum internally. The only changes needed after reverting are change EPdfDataType m_eDataType; to pdf_int8 m_eDataType; and in PdfVariant::GetDataType change return m_eDataType; to return (EPdfDataType)m_eDataType; I’ll do some testing them submit a patch. Best Regards Mark Mark Rogers - mark.rog...@powermapper.com PowerMapper Software Ltd - www.powermapper.com Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL On 16/02/2017, 18:50, "zyx" wrote: On Sat, 2017-02-11 at 03:12 +0100, Sandro Mani wrote: > 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. Hi, I would ideally use something like the attached change, but it has also caveats. It lets me compile the test example with any standard, even with c++98, while keeping the PoDoFo built with the default standard for the compiler, but as the enum is defined in a public header, then when I use lower-than c++11 (more precisely, when my compilation doesn't have required standard version, but PoDoFo had been built with new-enough C++ standard), the I get a warning from gcc: src/base/PdfCompilerCompat.h:202:29: warning: scoped enums only available with -std=c++11 or -std=gnu++11 #define PODOFO_ENUM_UINT8 : uint8_t Thus it can make, theoretically, a trouble. I do not see any good solution for this, maybe only revert this change (r1810) all together and change PdfVariant to not hold EPdfDataType m_eDataType; but pdf_int8 m_eDataType; instead, which would require some other internal changes possibly. I would not change the public API otherwise, the functions would still use the enum. Opinions? Bye, zyx -- http://www.litePDF.cz i...@litepdf.cz -- 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On Sat, 2017-02-11 at 03:12 +0100, Sandro Mani wrote:
> 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.
Hi,
I would ideally use something like the attached change, but it has also
caveats.
It lets me compile the test example with any standard, even with c++98,
while keeping the PoDoFo built with the default standard for the
compiler, but as the enum is defined in a public header, then when I
use lower-than c++11 (more precisely, when my compilation doesn't have
required standard version, but PoDoFo had been built with new-enough
C++ standard), the I get a warning from gcc:
src/base/PdfCompilerCompat.h:202:29: warning: scoped enums only
available with -std=c++11 or -std=gnu++11
#define PODOFO_ENUM_UINT8 : uint8_t
Thus it can make, theoretically, a trouble. I do not see any good
solution for this, maybe only revert this change (r1810) all together
and change PdfVariant to not hold
EPdfDataType m_eDataType;
but
pdf_int8 m_eDataType;
instead, which would require some other internal changes possibly. I
would not change the public API otherwise, the functions would still
use the enum.
Opinions?
Bye,
zyx
--
http://www.litePDF.cz i...@litepdf.czIndex: CMakeLists.txt
===
--- CMakeLists.txt (revision 1822)
+++ CMakeLists.txt (working copy)
@@ -22,6 +22,7 @@ SET(PODOFO_LIBVERSION "${PODOFO_SOVERSIO
#
INCLUDE(CheckIncludeFile)
INCLUDE(CheckLibraryExists)
+INCLUDE(CheckCXXSourceCompiles)
INCLUDE(TestBigEndian)
INCLUDE(CheckTypeSize)
@@ -296,9 +297,9 @@ IF(CMAKE_COMPILER_IS_GNUCXX)
SET(PODOFO_USE_VISIBILITY ${PODOFO_HAVE_GCC4})
ENDIF(NOT DEFINED PODOFO_USE_VISIBILITY)
-SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++98")
+SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
-SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Woverloaded-virtual -Wswitch-enum -Wcast-qual -Wwrite-strings -Wredundant-decls -Wreorder")
+SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Woverloaded-virtual -Wswitch-enum -Wcast-qual -Wwrite-strings -Wredundant-decls -Wreorder -Wno-deprecated-declarations")
#
# Note that we do not need debug definitions here. Set
@@ -442,6 +443,16 @@ ENDIF(LUA_FOUND)
ENDIF(NOT PODOFO_BUILD_LIB_ONLY)
+CHECK_CXX_SOURCE_COMPILES("
+ // Visual C++ 2015 (_MSC_VER 1900) still uses __cplusplus = 199711 so, we need both tests
+ // this shrinks enum types from sizeof(int) to sizeof(char) which creates significant
+ // space savings on PdfObject / PdfVariant
+ #if (defined(_MSC_VER) && _MSC_VER < 1900) || (!defined(_MSC_VER) && __cplusplus < 201103)
+ #error \"Cannot use uint8_t enums\"
+ #endif
+ int main(void) { return 0; }" PODOFO_HAVE_ENUM_UINT8)
+
+
# Check if we should build a multithreaded version of PoDoFo
IF(DEFINED PODOFO_NO_MULTITHREAD)
MESSAGE("Building non multithreaded version of PoDoFo.")
Index: podofo_config.h.in
===
--- podofo_config.h.in (revision 1822)
+++ podofo_config.h.in (working copy)
@@ -14,6 +14,7 @@
/* PoDoFo configuration options */
#cmakedefine PODOFO_MULTI_THREAD
+#cmakedefine PODOFO_HAVE_ENUM_UINT8
/* somewhat platform-specific headers */
#cmakedefine PODOFO_HAVE_STRINGS_H 1
@@ -46,6 +47,7 @@
/* Features */
#cmakedefine PODOFO_NO_FONTMANAGER
+
/* Libraries */
#cmakedefine PODOFO_HAVE_JPEG_LIB
#cmakedefine PODOFO_HAVE_PNG_LIB
Index: src/base/PdfCompilerCompat.h
===
--- src/base/PdfCompilerCompat.h (revision 1822)
+++ src/base/PdfCompilerCompat.h (working copy)
@@ -198,13 +198,10 @@ namespace PoDoFo {
#endif // defined(_WIN32)
-// Visual C++ 2015 (_MSC_VER 1900) still uses __cplusplus = 199711 so, we need both tests
-// this shrinks enum types from sizeof(int) to sizeof(char) which creates significant
-// space savings on PdfObject / PdfVariant
-#if (defined(_MSC_VER) && _MSC_VER < 1900) || (!defined(_MSC_VER) && __cplusplus < 201103)
-#define PODOFO_ENUM_UINT8
-#else
+#ifdef PODOFO_HAVE_ENUM_UINT8
#define PODOFO_ENUM_UINT8 : uint8_t
+#else
+#define PODOFO_ENUM_UINT8
#endif
--
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
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On Sat, 2017-02-11 at 03:12 +0100, Sandro Mani wrote: > 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. Hi, nice catch. So it's a mismatch between the compilation of the PoDoFo itself and the compilation of the application which uses PoDoFo. Let's populate PODOFO_ENUM_UINT8 in configure time, not in build time, which should make it work. I see a similar regression with respect of openssl headers being required when building against PoDoFo, which can result in the same issue. I currently deal with some other 0.9.5 regressions for which I have some fixes. I'll commit them once I finish the testing. Bye, zyx -- http://www.litePDF.cz i...@litepdf.cz -- 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
Hi all, I'm not using my Yahoo account anymore, also because of the break-in. > Sandro Mani has written on February 10, 2017 at 14:37: > On 08.02.2017 11:21, Sandro Mani wrote: > > > > > > However I can't reproduce it with the static library though, so it is > > definitely related to the shared library. > > > Hi > Dropping -std=c++98 "fixes" the issue for me. Is there a reason for > using -std=c++98? > > Sandro > > AFAIK, the reason is that PoDoFo still supports (IMHO) "rather ancient" compilers, i. e. Visual C++ 6, which don't support anything newer, so the flag is there to prevent incompatibilities from creeping in. I'm very sorry that I only now come to the fore with it (I've been rather busy with studies lately, for example): I smell that in src/base/PdfVariant.h, the C-style casts (GCC calls them "old-style casts") should be replaced by dynamic_cast (then the pragmas would be superfluous), however NULL checks would be required then, IMHO (raising exceptions for "invalid data type" on failing). Best regards, mabri -- 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
Has anyone attempted to analyze this issue using valgrind? (I have not yet). It smells like heap or stack corruption to me. On Fri, Feb 10, 2017 at 5:37 AM, Sandro Mani wrote: > > > On 08.02.2017 11:21, Sandro Mani wrote: > > > > > > However I can't reproduce it with the static library though, so it is > > definitely related to the shared library. > > > Hi > Dropping -std=c++98 "fixes" the issue for me. Is there a reason for > using -std=c++98? > > 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 > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > -- 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On 08.02.2017 11:21, Sandro Mani wrote: > > > However I can't reproduce it with the static library though, so it is > definitely related to the shared library. > Hi Dropping -std=c++98 "fixes" the issue for me. Is there a reason for using -std=c++98? 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On 08.02.2017 11:15, zyx wrote: > On Wed, 2017-02-08 at 00:58 +0100, Sandro Mani wrote: >> All this on Fedora rawhide. (I'm working on narrowing down as time >> allows). > Hi, > very interesting. I can make it crash with both your and mine code, > they are simply the same, but only if I compile the code against > installed library. Compiling it with the in-build-tree-code doesn't > cause any crash. There can be that there happened something during the > 'make install', maybe anything related to RPATH? > > Luckily, I guess, I get the same issue with gcc 6.2.1 when linking > against installed PoDoFo. Hi, Pretty sure it is not related to rpath / the installed library: $ g++ -g -o testprog test.cpp -L$PWD/src -lpodofo -I$PWD/dist/usr/local/include $ LD_LIBRARY_PATH=$PWD/src ./testprog terminate called after throwing an instance of 'PoDoFo::PdfError' Aborted (core dumped) $ LD_LIBRARY_PATH=$PWD/src ldd ./testprog libpodofo.so.0.9.5 => [...]/podofo-0.9.5/build/src/libpodofo.so.0.9.5 (0x7f384f1ac000) [...] However I can't reproduce it with the static library though, so it is definitely related to the shared library. 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On Wed, 2017-02-08 at 00:58 +0100, Sandro Mani wrote: > All this on Fedora rawhide. (I'm working on narrowing down as time > allows). Hi, very interesting. I can make it crash with both your and mine code, they are simply the same, but only if I compile the code against installed library. Compiling it with the in-build-tree-code doesn't cause any crash. There can be that there happened something during the 'make install', maybe anything related to RPATH? Luckily, I guess, I get the same issue with gcc 6.2.1 when linking against installed PoDoFo. Bye, zyx -- http://www.litePDF.cz i...@litepdf.cz -- 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On 07.02.2017 11:53, zyx wrote:
> On Mon, 2017-02-06 at 23:20 +0100, Sandro Mani wrote:
>> I'll narrow this down as time allows and file a GCC bug as soon as I
>> have a reduced test case (provided the narrowing down confirms my
>> miscompilation theory).
> Hi,
> I tried to reproduce this with gcc 7.0.1, but still no luck. It doesn't
> matter whether I compile PoDoFo as a static library (the default) or as
> a shared library, neither whether I use Boost or Lua or some other
> optional dependencies on or off (my podofo_config.h currently shows
> that I have all the development libraries installed and available).
>
> I use the attached code, which is the same as yours, it only avoids a
> memory leak and unused variable, thus neither gcc nor valgrind claim
> any issue. The file contain my steps (note the missing `make install`,
> the code is run out of the build tree) at the top of it.
>
> Maybe I do something wrong?
>
I can reproduce it with
$ cat test.cpp
#include
#include
#include
int main() {
PoDoFo::PdfStreamedDocument* document = new
PoDoFo::PdfStreamedDocument("test.pdf");
PoDoFo::PdfImage pdfImage(document);
PoDoFo::PdfDictionary& dictionary =
pdfImage.GetObject()->GetDictionary();
return 0;
}
$ cmake -DPODOFO_BUILD_SHARED=ON ..
$ make DESTDIR=$PWD/dist install
$ g++ -g -o testprog test.cpp -L$PWD/dist/usr/local/lib -lpodofo
-I$PWD/dist/usr/local/include -Wl,-rpath,$PWD/dist/usr/local/lib
$ ./testprog
terminate called after throwing an instance of 'PoDoFo::PdfError'
Aborted (core dumped)
Relevant cmake output:
Using gcc specific compiler options
-- Found ZLIB: /usr/lib64/libz.so
Found zlib headers in /usr/include, library at /usr/lib64/libz.so
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.2.2")
-- Checking for module 'libcrypto'
-- Found libcrypto, version 1.1.0d
-- Found LIBCRYPTO: /usr/lib64/libcrypto.so
-- Performing Test PODOFO_HAVE_OPENSSL_1_1
-- Performing Test PODOFO_HAVE_OPENSSL_1_1 - Success
Found OpenSSL's libCrypto headers in /usr/include, library at
/usr/lib64/libcrypto.so
-- Could NOT find LIBIDN (missing: LIBIDN_LIBRARY LIBIDN_INCLUDE_DIR)
Libidn not found. AES-256 Encryption support will be disabled
-- Found LIBJPEG: /usr/lib64/libjpeg.so
Found libjpeg headers in /usr/include, library at /usr/lib64/libjpeg.so
-- Found TIFF: /usr/lib64/libtiff.so
Found libtiff headers in /usr/include, library at /usr/lib64/libtiff.so
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
-- Found PNG: /usr/lib64/libpng.so (found version "1.6.28")
Found LibPng headers in /usr/include;/usr/include, library at
/usr/lib64/libpng.so;/usr/lib64/libz.so
-- Ensure you cppunit installed version is at least 1.12.0
-- Found cppunit: /usr/lib64/libcppunit.so
Found cppunit. Unit tests will be built.
-- Found OpenSSL: /usr/lib64/libssl.so
Found freetype library at /usr/lib64/libfreetype.so, headers
/usr/include/freetype2
-- Checking for module 'fontconfig'
-- Found fontconfig, version 2.12.1
-- Found Fontconfig: fontconfig;freetype
Found fontconfig headers in /usr/include, library at fontconfig;freetype
-- Could NOT find Lua50 (missing: LUA_LIBRARIES LUA_INCLUDE_DIR)
-- Could NOT find Lua (missing: LUA_LIBRARIES LUA_INCLUDE_DIR)
Lua not found - PoDoFoImpose and PoDoFoColor will be built without Lua
support
Building multithreaded version of PoDoFo.
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
Building shared PoDoFo library
Pkg-config found, creating a pkg-config file for linking against shared
library.
All this on Fedora rawhide. (I'm working on narrowing down as time allows).
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
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On Mon, 2017-02-06 at 23:20 +0100, Sandro Mani wrote:
> I'll narrow this down as time allows and file a GCC bug as soon as I
> have a reduced test case (provided the narrowing down confirms my
> miscompilation theory).
Hi,
I tried to reproduce this with gcc 7.0.1, but still no luck. It doesn't
matter whether I compile PoDoFo as a static library (the default) or as
a shared library, neither whether I use Boost or Lua or some other
optional dependencies on or off (my podofo_config.h currently shows
that I have all the development libraries installed and available).
I use the attached code, which is the same as yours, it only avoids a
memory leak and unused variable, thus neither gcc nor valgrind claim
any issue. The file contain my steps (note the missing `make install`,
the code is run out of the build tree) at the top of it.
Maybe I do something wrong?
Bye,
zyx
--
http://www.litePDF.cz i...@litepdf.cz/* Configure in /home/zyx/podofo-0.9.5/build/
$ cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/tmp/podofo -DCMAKE_BUILD_TYPE=Debug -DWANT_BOOST=ON -DPODOFO_BUILD_SHARED=ON ..
Build:
$ make
Compile and run the test:
$ g++ -g -O0 delayedload.cpp -o delayedload -L/home/zyx/podofo-0.9.5/build/src -rdynamic -lpodofo -lfontconfig -lz -lcrypto -ljpeg -lpthread -lfreetype -lpng -lz -lcrypto -ljpeg -lpthread -lfreetype -lpng -lidn -Wl,-rpath,/home/zyx/podofo-0.9.5/build/src -I/home/zyx/podofo-0.9.5/build -I/home/zyx/podofo-0.9.5 -I/home/zyx/podofo-0.9.5/src -I/usr/include/freetype2-std=c++98 -Wall -Woverloaded-virtual -Wswitch-enum -Wcast-qual -Wwrite-strings -Wredundant-decls -Wreorder -W -fvisibility=hidden -DPODOFO_HAVE_GCC_SYMBOL_VISIBILITY -ltiff && ./delayedload
*/
#include
#include "podofo.h"
using namespace PoDoFo;
int main(void)
{
PdfError::EnableLogging(true);
try {
PdfStreamedDocument *document = new PdfStreamedDocument("/tmp/delayedload.pdf");
PdfImage pdfImage(document);
PdfDictionary &dictionary = pdfImage.GetObject()->GetDictionary();
printf ("All fine; has XXX:%d\n", dictionary.HasKey(PdfName("XXX")));
delete document;
} catch (const PdfError &error) {
fprintf (stderr, "Failed with error:\n");
error.PrintErrorMsg();
}
return 0;
}
--
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
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On 06.02.2017 16:56, zyx wrote:
> On Mon, 2017-02-06 at 10:57 +0100, Sandro Mani wrote:
>> Yes 0.9.4 works well. I initially suspected a compiler bug since
>> gcc-7.0.1 just landed in Fedora rawhide, but the same error happens
>> with gcc-6.3.1 (although this doesn't completely exclude that 6.3.1
>> might be miscompiling).
> Hi,
> I made my build with gcc 6.2.1. I cannot test with 7.0.1 at the moment,
> the machine doesn't want to connect anywhere. I do not know why. I'll
> let you know if I find anything.
>
Investigating further this really looks like a miscompilation
│544 #endif
B+ │545 if( !m_bDelayedLoadDone)
│546 {
│547 #if defined(PODOFO_EXTRA_CHECKS)
│548 m_bDelayedLoadInProgress = true;
│549 #endif
>│550 const_cast(this)->DelayedLoadImpl();
│551 // Nothing was thrown, so if the implementer of
DelayedLoadImpl()
│552 // following the rules we're done.
│553 m_bDelayedLoadDone = true;
│554 #if defined(PODOFO_EXTRA_CHECKS)
│555 m_bDelayedLoadInProgress = false;
│556 #endif
│557 }
│558 }
Breakpoint 1, PoDoFo::PdfVariant::DelayedLoad (this=0x615ed0)
at /usr/src/debug/podofo-0.9.5/src/base/PdfVariant.h:545
545 if( !m_bDelayedLoadDone)
(gdb) print m_bDelayedLoadDone
$1 = true
(gdb) next
550 const_cast(this)->DelayedLoadImpl();
(gdb) print m_bDelayedLoadDone
$2 = true
So the if block is entered despite m_bDelayedLoadDone=true (and
PdfVariant::Clear is also called for the matter, and a watchpoint on
m_bDelayedLoadDone does not trigger after PdfVariant::Clear).
I'll narrow this down as time allows and file a GCC bug as soon as I
have a reduced test case (provided the narrowing down confirms my
miscompilation theory).
Best
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
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On Mon, 2017-02-06 at 10:57 +0100, Sandro Mani wrote: > Yes 0.9.4 works well. I initially suspected a compiler bug since > gcc-7.0.1 just landed in Fedora rawhide, but the same error happens > with gcc-6.3.1 (although this doesn't completely exclude that 6.3.1 > might be miscompiling). Hi, I made my build with gcc 6.2.1. I cannot test with 7.0.1 at the moment, the machine doesn't want to connect anywhere. I do not know why. I'll let you know if I find anything. Bye, zyx -- http://www.litePDF.cz i...@litepdf.cz -- 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On 06.02.2017 10:09, zyx wrote: > On Mon, 2017-02-06 at 08:03 +0100, Sandro Mani wrote: >> Hunting for a fix / workaround. > Hi, > that's odd. I cannot reproduce it here, no exception is thrown, neither > valgrind claims anything wrong. > > As the comment in PdfVariant::Init() says, every PdfVariant() > constructor calls Clear(), which sets the m_bDelayedLoadDone to true. > > Does the same code work properly with PoDoFo 0.9.4 for you? > Hi Yes 0.9.4 works well. I initially suspected a compiler bug since gcc-7.0.1 just landed in Fedora rawhide, but the same error happens with gcc-6.3.1 (although this doesn't completely exclude that 6.3.1 might be miscompiling). Also, compiling without optimization (-O0) results in the same error. I'll keep looking. Best 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
On Mon, 2017-02-06 at 08:03 +0100, Sandro Mani wrote: > Hunting for a fix / workaround. Hi, that's odd. I cannot reproduce it here, no exception is thrown, neither valgrind claims anything wrong. As the comment in PdfVariant::Init() says, every PdfVariant() constructor calls Clear(), which sets the m_bDelayedLoadDone to true. Does the same code work properly with PoDoFo 0.9.4 for you? By the way, you should include "podofo.h", not each header separately. Bye, zyx -- http://www.litePDF.cz i...@litepdf.cz -- 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
Hi
I'm hitting an exception with podofo-0.9.5 with the following code:
---
#include
#include
#include
int main() {
PoDoFo::PdfStreamedDocument* document = new
PoDoFo::PdfStreamedDocument("test.pdf");
PoDoFo::PdfImage pdfImage(document);
PoDoFo::PdfDictionary& dictionary =
pdfImage.GetObject()->GetDictionary();
return 0;
}
---
This results in an exception in PoDoFo::PdfVariant::DelayedLoadImpl
│911 void PdfVariant::DelayedLoadImpl()
│912 {
│913 // Default implementation of virtual void
DelayedLoadImpl() throws, since delayed
│914 // loading should not be enabled except by types that
support it.
>│915 PODOFO_RAISE_ERROR( ePdfError_InternalLogic );
│916 }
Valgrind reports:
==16529== Conditional jump or move depends on uninitialised value(s)
==16529==at 0x400BFF: PoDoFo::PdfVariant::DelayedLoad() const
(PdfVariant.h:545)
==16529==by 0x400C3B: PoDoFo::PdfVariant::GetDictionary()
(PdfVariant.h:851)
==16529==by 0x400B84: main (test.cpp:8)
It appears that m_bDelayedLoadDone is uninitialized and, if unlucky,
results in this behaviour.
Hunting for a fix / workaround.
Best
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
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
