Bug 7903 - Non-initialized variable and strange behaviour usin streams
Summary: Non-initialized variable and strange behaviour usin streams
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-16 01:53 UTC by Stephane Magnenat
Modified: 2009-06-17 14:09 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Test-case for the bug described in the report (4.90 KB, text/x-c++src)
2006-08-16 01:54 UTC, Stephane Magnenat
Details
Makefile for the testcase (89 bytes, text/x-makefile)
2006-08-16 01:54 UTC, Stephane Magnenat
Details

Description Stephane Magnenat 2006-08-16 01:53:00 UTC
Hello,

I would like to make an helper application for indexing pdf articles into a 
bibliographic database. As a first step, I've made a pdf structure dumper 
using popple. In the course of writing it, I've run into some problems. 
Finding how things are supposed to work is not easy because there is no 
documentation on poppler. To get to the report exposed below, I've made 
extensive use of valgrind. If those are not bugs, but missunderstanding from 
my part, please excuse me.

* Non-initialized variable

A stream of type strFile does return a non-NULL dict through getDict(), but 
this dict's length field is a non-initialized variable. 
This leaded me to add the check at line 43 of pdfds.cpp

* Strange addFilters behaviour

Every time I try to get an uncompress substream of a Flate encoded stream 
(lines 58 to 75 of pdfds.cpp), I get "Error (some int here): Unknown 
compression method in flate stream". Yet the dict does have the correct 
parameters and afaik is passed correctly to addFilters. It's perhaps a bug on 
my side, as addFilters does not seem that complex in fdo's cvs, but I can't 
find what.

Thanks a lot, have a nice day,

Steph

P.S. I was using libpoppler version 0.5.3-0ubuntu1 on Ubuntu Dapper
Comment 1 Stephane Magnenat 2006-08-16 01:54:00 UTC
Created attachment 6581 [details]
Test-case for the bug described in the report
Comment 2 Stephane Magnenat 2006-08-16 01:54:23 UTC
Created attachment 6582 [details]
Makefile for the testcase
Comment 3 Albert Astals Cid 2006-08-16 02:24:23 UTC
A stream of type strFile returns the dict you passed to it in the constructor, 
if that dict is "wrong" probably is your fault.

Are you using a zlib enabled poppler? This can cause misbehaviour in Flate 
Streams.

By the way that seems much more a thing to deal on the mailing list or irc 
than on bugzilla.
Comment 4 Stephane Magnenat 2006-08-16 13:39:59 UTC
(In reply to comment #3)
> A stream of type strFile returns the dict you passed to it in the 
constructor, 
> if that dict is "wrong" probably is your fault.

The stream in question was the basestream returned by the PDFDoc object, so I 
supposed allocating the stream's members was the responsability of the PDFDoc 
constructor, did I missed something here ?
 
> Are you using a zlib enabled poppler? This can cause misbehaviour in Flate 
> Streams.

I'm using ubuntu deb. ldd /usr/lib/libpoppler.so does say libz is linked in. 
Is there another way to know wether zlib is enabled or not ?
Nevertheless I don't think my libpoppler is buggy as kpdf works fine. I just 
probably have missed something about the API.

> By the way that seems much more a thing to deal on the mailing list or irc 
> than on bugzilla.

Ok, I will direct further question/remarks there.

Thanks

Steph
Comment 5 Brad Hards 2007-12-24 19:37:20 UTC
Is anything still required on this issue?
Comment 6 Albert Astals Cid 2009-06-17 14:09:27 UTC
1.5 years and no answer to Brad, i'll take it as a "no"


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.