• Bug#254864: [[email protected]: Bug#254864: xpdf-japanese: segfaul

    From Hamish Moffatt@1:229/2 to Derek B. Noonburg on Wed Aug 18 13:00:12 2004
    From: [email protected]

    On Tue, Aug 17, 2004 at 11:27:43AM -0700, Derek B. Noonburg wrote:
    Here's another Xpdf-crashes bug report. It seems to segfault in
    Freetype. I have Freetype 2.1.7 installed.

    I can't reproduce the problem with this file either.

    What does the stack trace look like? The one that I saw for bug #260896
    was kind of strange -- multiple frames claiming to be inside putchar(),
    which doesn't make any sense (maybe a corrupted stack?)

    Here's the stack trace I get with this one. It's with an Xpdf binary
    compiled with FT 2.1.7. The crash happens when you get to about page 6.

    Hamish

    #0 0x4008a69d in FT_Outline_Decompose () from /usr/lib/libfreetype.so.6
    #1 0x080d5cb1 in SplashFTFont::getGlyphPath (this=0x0, c=141303848)
    at SplashFTFont.cc:229
    #2 0x0809e55b in SplashOutputDev::drawChar (this=0x8173840, state=0x81b2d08,
    x=10.500000000000002, y=0, dx=10.619700000000002, dy=0, originX=0,
    originY=0, code=864, u=0xbfffeea0, uLen=1) at SplashOutputDev.cc:871
    #3 0x0805e95f in Gfx::doShowText (this=0x81aeae0, s=0x86c20b0)
    at GfxState.h:913
    #4 0x08058d17 in Gfx::execOp (this=0x81aeae0, cmd=0x8, args=0xbfffef50,
    numArgs=1) at Gfx.cc:660
    #5 0x08058957 in Gfx::go (this=0x81aeae0, topLevel=1) at Gfx.cc:551
    #6 0x080587ea in Gfx::display (this=0x81aeae0, obj=0xbffff0b0, topLevel=8)
    at Gfx.cc:523
    #7 0x08091360 in Page::displaySlice (this=0x81a2ca0, out=0x8173840, hDPI=90,
    vDPI=90, rotate=0, crop=1, sliceX=-1, sliceY=-1, sliceW=-1,
    sliceH=135981792, links=0x81a4928, catalog=0x81a0ee8, abortCheckCbk=0x8,
    abortCheckCbkData=0x8) at Page.cc:319
    #8 0x08091004 in Page::display (this=0x8, out=0x8, hDPI=0.11970000000000003,
    vDPI=0.11970000000000003, rotate=8, crop=8, links=0x8, catalog=0x8,
    abortCheckCbk=0x8, abortCheckCbkData=0x8) at Page.cc:226
    #9 0x080b4712 in XPDFCore::displayPage (this=0x8172ba0, pageA=1, zoomA=0,
    rotateA=8, scrollToTop=1, addToHist=1) at XPDFCore.cc:513
    #10 0x080b4c08 in XPDFCore::gotoNextPage (this=0x0, inc=1, top=1)
    at XPDFCore.cc:622
    #11 0x080b5080 in XPDFCore::scrollPageDown (this=0x8172ba0) at XPDFCore.cc:715 #12 0x080b719f in XPDFCore::inputCbk (widget=0x8173708, ptr=0x8172ba0,
    callData=0xbffff2c0) at XPDFCore.cc:1749
    #13 0x4027f8d9 in XtCallCallbackList () from /usr/X11R6/lib/libXt.so.6
    #14 0x4014ce5b in _XmDrawingAreaInput () from /usr/lib/libXm.so.2
    #15 0x402b36b7 in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6
    #16 0x402b3beb in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6
    #17 0x402b41e3 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6
    #18 0x4028c73b in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6
    #19 0x4028d284 in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6
    #20 0x4028d43f in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
    #21 0x4028d994 in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
    #22 0x080c501d in main (argc=2, argv=0x0) at xpdf.cc:288
    --
    Hamish Moffatt VK3SB <[email protected]> <[email protected]>


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Hamish Moffatt@1:229/2 to Derek B. Noonburg on Wed Aug 18 15:30:11 2004
    From: [email protected]

    On Tue, Aug 17, 2004 at 11:27:43AM -0700, Derek B. Noonburg wrote:
    Here's another Xpdf-crashes bug report. It seems to segfault in
    Freetype. I have Freetype 2.1.7 installed.

    I can't reproduce the problem with this file either.

    What does the stack trace look like? The one that I saw for bug #260896
    was kind of strange -- multiple frames claiming to be inside putchar(),
    which doesn't make any sense (maybe a corrupted stack?)

    Hi Derek,

    I found an explanation for this by poking through the FreeType code. (I compiled Xpdf with FreeType 2.1.9 and it didn't help).

    FT 2.1.9's <freetype/ftoutln.h> has a comment saying you can typecast an FT_Glyph to FT_OutlineGlyph if glyph->format ==
    FT_GLYPHY_FORMAT_OUTLINE. I found that in that PDF, the type was not
    _OUTLINE but actually _BITMAP.

    I added a check in Xpdf's splash/SplashFTFont.cc at around line 228 to
    check that the format is actually _OUTLINE before calling
    FT_Outline_Decompose, and now it doesn't crash.

    I have no idea if this is a good fix though.

    Hamish
    --
    Hamish Moffatt VK3SB <[email protected]> <[email protected]>


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)