[gs-bugs] [Bug 691532] jbig2dec segfault caused by new image reference counts

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Mon Aug 9 05:38:18 UTC 2010


Henry Stiles <henry.stiles at artifex.com> changed:

           What    |Removed                     |Added
                 CC|                            |tor.andersson at artifex.com

--- Comment #3 from Henry Stiles <henry.stiles at artifex.com> 2010-08-09 05:38:16 UTC ---
xpdf and mupdf both crash on this as well.  Adobe (Acrobat 8) and Apple Preview
each have wrong output.  I can't find a rip that prints this reasonably. 

The first segment header appears to be corrupt:

0x0, 0x0, 0x0, 0x1, 0x40, 0x0, 0x0, 0x33, 0x33, 0x33, 0x13, 0x0, 0x0, 0xa

(section numbers from the draft spec cited at http://jbig2dec.sourceforge.net/)


[0-3] 0x0 0x0 0x0 0x1,  segment number 1.  


[4] 0x40 - segment type = 0 (symbol dictionary), the page association field is
4 bytes long


[5] 0x0 - segment referred to segment count


[6-9]  0x0, 0x33, 0x33, 0x33 - page association is 3,355,443 (probably corrupt

[10-13] 0x13, 0x0, 0x0, 0xa - segment data length 318767114!

There is not enough data in the file so an underflow condition should be
triggered but the code continues until the stream returns EOF at which point
jbig2dec assumes a page image is available.  There are several suspicious areas
here that need study.  The patch provided by Tim in comment #1 is fine as a
work around solution.

Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the gs-bugs mailing list