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
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users
