Bug 28480 - pipe->destAlphaPtr out of bounds during render
Summary: pipe->destAlphaPtr out of bounds during render
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: splash backend (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium minor
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-10 03:47 UTC by Harry Roberts
Modified: 2010-06-15 15:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Single page from a PDF 100+ page PDF, only this page triggers the bug. (710.76 KB, application/pdf)
2010-06-10 03:50 UTC, Harry Roberts
Details
Test program to replicate the issue (1.29 KB, application/octet-stream)
2010-06-11 06:26 UTC, Harry Roberts
Details

Description Harry Roberts 2010-06-10 03:47:52 UTC
I'm trying to work out if this is a regression in poppler/splash or my app, a previous build of my app (using poppler git from around mid april) seems to not have this problem.

I'm posting here because I can't think of a reason why destAlphaPtr would end up being invalid, and my efforts to find the cause of this have been futile.

Latest commit in my poppler tree is:
commit eb0206ba8458f1dba004ac7bef856dcbb2ccbba5
Author: Albert Astals Cid <aacid@kde.org>
Date:   Wed Jun 9 18:56:16 2010 +0100

GDB Backtrace:
Splash::pipeRun (this=0x819fb58, pipe=0xf738bb30) at Splash.cc:296
296	      *pipe->destAlphaPtr++ = 255;

(gdb) bt
#0  Splash::pipeRun (this=0x819fb58, pipe=0xf738bb30) at Splash.cc:296
#1  0x080b608c in Splash::drawImage (this=0x819fb58, src=0x8051de0 <SplashOutputDev::imageSrc(void*, unsigned char*, unsigned char*)>, srcData=0xf738bc04, srcMode=splashModeRGB8, 
    srcAlpha=0, w=1, h=160, mat=0xf738bbd0) at Splash.cc:651
#2  0x080518ef in SplashOutputDev::drawImage (this=0x819fa50, state=0x81dd118, ref=0xf738be78, str=0x81e3890, width=1, height=160, colorMap=0x81e42c8, interpolate=0, maskColors=0x0, 
    inlineImg=0) at SplashOutputDev.cc:2388
#3  0x08100df7 in Gfx::doImage (this=0x81bbb18, ref=0xf738be78, str=0x81e3890, inlineImg=0) at Gfx.cc:4172
#4  0x0810592e in Gfx::opXObject (this=0x81bbb18, args=0xf738bef0, numArgs=1) at Gfx.cc:3779
#5  0x080f77bb in Gfx::go (this=0x81bbb18, topLevel=1) at Gfx.cc:700
#6  0x080f7c14 in Gfx::display (this=0x81bbb18, obj=0xf738c15c, topLevel=1) at Gfx.cc:667
#7  0x0807779d in Page::displaySlice (this=0x81a0350, out=0x819fa50, hDPI=169.33327375310739, vDPI=169.33327375310739, rotate=0, useMediaBox=1, crop=0, sliceX=55, sliceY=55, sliceW=1533, 
    sliceH=2000, printing=1, catalog=0x819e240, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at Page.cc:474
#8  0x0804c115 in displayPageSlice (out=0x819fa50, rect=0xf62c5dd6, page=0x0, catalog=0x819e240) at panda.cc:332
#9  0x0804d642 in ImageOutputWorker::executeThis (this=0x819e690) at panda.cc:355
#10 0x0804e836 in ThreadPool::threadExecute (param=0xff8f663c) at threadpool.cpp:129
#11 0xf73baf3b in start_thread () from /lib/libpthread.so.0
#12 0xf7497bee in clone () from /lib/libc.so.6

(gdb) p *pipe
$1 = {x = 1345, y = -1, pattern = 0x0, aInput = 1, usesShape = 0, aSrc = 255 '?', cSrc = 0xf738bb7c "???", cSrcVal = "?8\036\b", alpha0Ptr = 0x0, 
  softMaskPtr = 0x4 <Address 0x4 out of bounds>, destColorPtr = 0xf62c5dd6 "", destColorMask = 0, destAlphaPtr = 0xf5fd8f4c <Address 0xf5fd8f4c out of bounds>, 
  shape = 6.6988234778194503e-270, noTransparency = 1, resultColorCtrl = splashPipeResultColorNoAlphaBlendRGB, nonIsolatedGroup = 0}

(gdb) p *this
$2 = {static pipeResultColorNoAlphaBlend = 0x817faf8, static pipeResultColorAlphaNoBlend = 0x817fb0c, static pipeResultColorAlphaBlend = 0x817fb20, 
  static pipeNonIsoGroupCorrection = <optimized out>, bitmap = 0x819e380, state = 0x81d5250, aaBuf = 0x0, aaBufY = 135915648, alpha0Bitmap = 0xb0efe, alpha0X = 0, alpha0Y = 0, aaGamma = {
    3.4611108497651681e+44, 7.000369473871096e-77, 1.7970939337735864e+78, 9.1246735815933728e+130, 1.3086590626776691e+180, 9.7057113096761042e+189, 9.7057113096512465e+189, 
    4.3228174217783677e-82, 1.4285356265651522e+248, 5.8943965252007285e-259, 2.4381298493579823e-152, 5.0584191739155448e+92, 9.2361473531496466e+242, 1.9683586588127569e-259, 
    8.714044211050804e+227, 1.2067967591876369e-153, 5.8854722815101661e-62}, modXMin = 0, modYMin = 0, modXMax = 1532, modYMax = 1999, opClipRes = splashClipPartial, 
  vectorAntialias = 0, debugMode = 0}
Comment 1 Harry Roberts 2010-06-10 03:50:21 UTC
Created attachment 36195 [details]
Single page from a PDF 100+ page PDF, only this page triggers the bug.
Comment 2 Albert Astals Cid 2010-06-10 12:10:39 UTC
Any reason you are not using poppler 0.14.0? I can not reproduce any crash using it.
Comment 3 Harry Roberts 2010-06-11 06:26:14 UTC
Created attachment 36215 [details]
Test program to replicate the issue
Comment 4 Harry Roberts 2010-06-11 06:29:01 UTC
I've attached a program which replicates the bug with the attached test.pdf.

(In reply to comment #2)
> Any reason you are not using poppler 0.14.0? I can not reproduce any crash
> using it.
Comment 5 Albert Astals Cid 2010-06-12 06:58:02 UTC
Ok, can reproduce the problem now, it happens when disabling vector antialias, the problem has been there for a long time though, will try to have a look
Comment 6 Harry Roberts 2010-06-12 16:08:27 UTC
I've been using poppler without vector antialiasing for a while and it's the first time I've seen it happen, so it's not really a big issue.

(In reply to comment #5)
> Ok, can reproduce the problem now, it happens when disabling vector antialias,
> the problem has been there for a long time though, will try to have a look
Comment 7 Albert Astals Cid 2010-06-15 15:03:52 UTC
Should be fixed in poppler 0.14.1


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.