Menu ▾ ▴

#71 Unusable public PdfTokenizer default constructor

SVN TRUNK
open
Matthew Brincke
None
2019-10-29
2019-10-23
Pietro
No

The default constructor of PdfTokenizer is unusable because you can't set the device or buffer to be tokenized from, from the "outside" (i.e. not subclasses) when having used that constructor. Therefore the default constructor should be relegated to being "protected". N.B. the first few comments on this issue reference an earlier state of this report, but it's gone as it's invalid.

Discussion

  • Pietro

    Pietro - 2019-10-23

    I had a quick go and the problem seems to stem from the fact that the m_device of PdfTokenizer is not inizialisated when the constructor PdfContentsTokenizer( Canvas ) gets used.

    That in turns uses the PdfTokenizer() constructor which does not init the m_device

    PdfContentsTokenizer::PdfContentsTokenizer( PdfCanvas* pCanvas )
    : PdfTokenizer(), m_readingInlineImgData(false)

     

  • Pietro

    Pietro - 2019-10-23

    If I can help in sorting out the previous point please let me know, I am happy to help. The bug report has to be considered invalid though as there is GIANT mistake in my code... sorry I am still getting to grips with C++ from a C background.

    char * p = new char(1024 * 1024) // Isn't correct at all.

     

    • Matthew Brincke

      Matthew Brincke - 2019-10-28

      You should have used at least: new char[1024 * 1024] (there can be better ways still). Does it work then?

       

      • Pietro

        Pietro - 2019-10-29

        Hi,

        Since I corrected that specific problem has disappeared, yes.

        Yeah, this is what I flagged up in my previous comment on the ticket.

        This bug is invalid and although I did find a SIGSEGV caused by the
        m_device being null, and that is somehow caused by the use of that
        constructor. If I manage to replicate that (without going around and
        writing stuff at random locations on the heap) I will raise a specific
        ticket for it. For now nevermind.

        Cheers,
        P.

         

        Last edit: Matthew Brincke 2019-10-29

        • Matthew Brincke

          Matthew Brincke - 2019-10-29

          Do you mind if I "recycle" this issue to track what I've edited the title to already, with change of the issue text to reflect that?

           

          • Pietro

            Pietro - 2019-10-29

            Of course, no problem at all. In fact I am sorry for the confusion...

             

            Last edit: Matthew Brincke 2019-10-29

  • Matthew Brincke

    Matthew Brincke - 2019-10-28
    • summary: ReadNext() results in sigsev --> Unusable public PdfTokenizer default constructor
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,5 +1,5 @@
 Hi all,

-It is not clear if I am doing anything silly here. I am using the PdfContentTokenizer to read a pdf stream and I am simply writing it in a buffer using the PdfOutputDevice. Doing so results in a sigsev, however removing all calls to the PdfOutPutDevice for the PdfVariant as pointed out in the attached file "fixes" the issue.
+It is not clear if I am doing anything silly here. I am using the PdfContentTokenizer to read a pdf stream and I am simply writing it in a buffer using the PdfOutputDevice. Doing so results in a sigsegv, however removing all calls to the PdfOutputDevice for the PdfVariant as pointed out in the attached file "fixes" the issue.

 I checked and re-checked but I can't see anything wrong with it.
    • assigned_to: Matthew Brincke
     

  • Matthew Brincke

    Matthew Brincke - 2019-10-29
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,5 +1 @@
-Hi all,
-
-It is not clear if I am doing anything silly here. I am using the PdfContentTokenizer to read a pdf stream and I am simply writing it in a buffer using the PdfOutputDevice. Doing so results in a sigsegv, however removing all calls to the PdfOutputDevice for the PdfVariant as pointed out in the attached file "fixes" the issue.
-
-I checked and re-checked but I can't see anything wrong with it.
+The default constructor of PdfTokenizer is unusable because you can't set the device or buffer to be tokenized from, from the "outside" (i.e. not subclasses) when having used that constructor. Therefore the default constructor should be relegated to being "protected". N.B. the first few comments on this issue reference an earlier state of this report, but it's gone as it's invalid.
     
MongoDB Logo MongoDB