Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception

[zyx]

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

[zyx]

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

[zyx]

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

[Matthew Brincke]

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

[Dennis Jenkins]

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

[Sandro Mani]

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

[Sandro Mani]

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

[zyx]

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  = pdfImage.GetObject()->GetDictionary();
		printf ("All fine; has XXX:%d\n", dictionary.HasKey(PdfName("XXX")));
		delete document;
	} catch (const PdfError ) {
		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

[zyx]

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