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<PdfVariant*>(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<PdfVariant*>(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