Hello Hartmut, Thank you for the very interesting explanations.
I have seen certain "strange" crashes in some places related to PdfVariant and
assignment, which I never could trace back to an actual reason. Maybe you just
found the cause for it.
I think, the class layout in Windows and Linux will assure that this code
worked most of the time.
Still, we definitly have to solve this issue. If I understood you correctly,
you changed all the reinterpret casts in PdfVariant.h to plain old C-style
casts. Is this correct?
I would prefer a solution without c-style casts. But I do not see a way how to
do this. Right now your change clutters the compiler output with lot's of GCC
warnings abotu old-style casts and "#pragma GCC diagnostic ignored" does not
seem to work...
Of course the warning is better than a crash. Let me think a while about this.
Maybe we can come up with another solution.
Cheers,
Dominik
Am Tuesday 21 June 2011 schrieb [email protected]:
> Hi all,
>
> it took me a long time to build Podofo on Sun Solaris using the native Sun
> Studio compiler.
> For several reasons I could not use gcc, where everything worked fine.
>
> With Sun Studio I ran into SIGSEGV crash (helloworld example).
>
> As helloword sample runs fine on other machines and compilers I first
> blamed Sun Studio for the crash.
> But after some investigations, I think, that the problem is inside Podofo.
>
> The problem is inside PdfVariant,
> the member Variable m_Data.pData is of type PdfDataType* .
>
> PdfDataType is an interface for real datatype classes, such as PdfArray.
> Any real datatype class has multiple inheritance (I like Java!),.
> PdfArray is derived from vector and PdfDataType.
>
> In PdfVariant.cpp , operator=, m_Data.pData is assigned as
>
> case ePdfDataType_Array:
> {
> if( rhs.m_Data.pData )
> m_Data.pData = new PdfArray(
> *(static_cast<PdfArray*>(rhs.m_Data.pData)) );
> break;
> }
>
> As pData is of type PdfDataType, a pointer to the PdfDataType part of the
> PdfArray is assigned.
> In the debugger, if the code is slightly changed
> PdfArray pNew = new PdfArray(
> *(static_cast<PdfArray*>(rhs.m_Data.pData)) );
> m_Data.pData = pNew;
>
> Under dbx you see: m_Data.pData is NOT equal pNew, but pNew + (offset
> PdfDataType in PdfArray).
>
> Later, going back from m_Data.pData to PdfArray in PdfVariant.h,
> a reinterpret_cast is used and the pointer is unchanged in assigment.
>
> PdfArray & PdfVariant::GetArray_NoDL()
> {
> // Test against eDataType directly not GetDataType() since
> // we don't want to trigger a delayed load (and if required one has
> // already been triggered).
> if( m_eDataType != ePdfDataType_Array )
> {
> PODOFO_RAISE_ERROR( ePdfError_InvalidDataType );
> }
> return *(reinterpret_cast<PdfArray* const>(m_Data.pData));
> }
>
> The reinterpret_cast is causing the crash as pData points to to the
> PdfDataype part, not to PdfArray.
> If the vector part of the PdfArray is accessed, the crash occurs.
>
> My suggestion is to just remove the reinterpret_cast, so that assignment
> and back assignment are symmetric.
>
> After replacing the reinterpret_cast (on severall occurrences) in
> PdfVariant.h, for example
>
> // return *(reinterpret_cast<PdfArray* const>(m_Data.pData));
> return *(PdfArray*)m_Data.pData;
>
> everything worked well, on Sun Studio compiler and several other
> platforms.
>
> Why did the problem not occur in other environments?
> Probably because the class layout is different, so that the PdfDatatype
> part in compound objects comes
> always first (offset 0).
> Then, the reinterpret_cast does no harm.
>
> friendly regards
> Hartmut Haas
>
> TONBELLER AG
> Werner-von-Siemens-Str. 2
> D-64625 Bensheim
> Germany
>
> www.tonbeller.com
>
> Register Court: District Court Darmstadt / Registration: HRB 21474
> Managing Board: Rutger Hetzler (CEO), Sebastian Hetzler, Torsten Mayer
> Chairman of the Supervisory Board: Rüdiger Brand
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any unauthorised copying or dissemination of this message is
> strictly prohibited. Diese E-Mail enthält vertrauliche und/oder rechtlich
> geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder
> diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
> Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie
> die Weitergabe dieser E-Mail ist nicht gestattet.
--
Dominik Seichter - [email protected] - http://domseichter.blogspot.com
KRename - http://www.krename.net - Powerful batch renamer for KDE
KBarcode - http://www.kbarcode.net - Barcode and label printing
PoDoFo - http://podofo.sf.net - PDF generation and parsing library
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
