<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear mpsuzuki!<br>
<br>
You can stop searching for it: is caused by a change I made on 8th
of january during xpdf 3.0.3 merge for rotated images:<br>
The calculation of scaledHeight in Splash::arbitraryTransformImage
of xpdf 3.0.3 doesn't support that a image can also be rotated
between 0 and 90° and then more pixel in Y direction will be needed.
But my correction has a kind of overflow, so I need to have a deeper
look into it.<br>
I already made a quick and dirty change in
Splash::arbitraryTransformImage which just limits the scaledHeight
for rotated images, and with this the bogus memory allocation size
disappears:<br>
<br>
if (mat[2] >= 0) {<br>
t0 = imgCoordMungeUpper(mat[2] + mat[4]) -
imgCoordMungeLower(mat[4]);<br>
if (splashAbs(mat[1]) >= 1) {<br>
th = imgCoordMungeUpper(mat[2]) - imgCoordMungeLower(mat[0] *
mat[3] / mat[1]);<br>
if (th > t0 && <b>th < 10000</b>) t0 = th;<br>
}<br>
} else {<br>
t0 = imgCoordMungeUpper(mat[4]) - imgCoordMungeLower(mat[2] +
mat[4]);<br>
if (splashAbs(mat[1]) >= 1) {<br>
th = imgCoordMungeUpper(mat[0] * mat[3] / mat[1]) -
imgCoordMungeLower(mat[2]);<br>
if (th > t0 && <b>th < 10000</b>) t0 = th;<br>
}<br>
}<br>
if (mat[3] >= 0) {<br>
t1 = imgCoordMungeUpper(mat[3] + mat[5]) -
imgCoordMungeLower(mat[5]);<br>
if (splashAbs(mat[0]) >= 1) {<br>
th = imgCoordMungeUpper(mat[3]) - imgCoordMungeLower(mat[1] *
mat[2] / mat[0]);<br>
if (th > t1 && <b>th < 10000</b>) t1 = th;<br>
}<br>
} else {<br>
t1 = imgCoordMungeUpper(mat[5]) - imgCoordMungeLower(mat[3] +
mat[5]);<br>
if (splashAbs(mat[0]) >= 1) {<br>
th = imgCoordMungeUpper(mat[1] * mat[2] / mat[0]) -
imgCoordMungeLower(mat[3]);<br>
if (th > t1 && <b>th < 10000</b>) t1 = th;<br>
}<br>
}<br>
scaledHeight = t0 > t1 ? t0 : t1;<br>
<br>
Cheers,<br>
Thomas<br>
<br>
Am 05.05.2012 09:48, schrieb suzuki toshiya:
<blockquote cite="mid:4FA4DB5D.8030102@hiroshima-u.ac.jp"
type="cite">
<pre wrap="">Thanks, when I work for another issue, I will try to use git bisect.
I found the issue starts since:
commit b505920db6d3dac58c7e9f4f8917f4c4449b08a0
Merge: 9250449 a631281
Author: Albert Astals Cid <a class="moz-txt-link-rfc2396E" href="mailto:aacid@kde.org"><aacid@kde.org></a>
Date: Tue Feb 14 19:18:54 2012 +0100
Merge remote-tracking branch 'origin/xpdf303merge'
Conflicts:
utils/HtmlOutputDev.cc
utils/HtmlOutputDev.h
However, I don't think 0.18.x is good and 0.19.x is bad.
I'm afraid that some overflow error occurs in 0.18.x but ignored silently.
I will check how the error occurs.
Regards,
mpsuzuki
Reece Dunn wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 5 May 2012 08:13, suzuki toshiya <a class="moz-txt-link-rfc2396E" href="mailto:mpsuzuki@hiroshima-u.ac.jp"><mpsuzuki@hiroshima-u.ac.jp></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I'm quite sorry! My posts assuming the error is 64-bit CPU specific
were wrong. I could reproduce the error on Linux i386 (I was testing
wrong revisions). I found 0.19.4 - 0.19.0 have this issue, but 0.18.4
does not have. Now I'm trying to find when this issue began.
</pre>
</blockquote>
<pre wrap="">
On one of the linux boxes, you can do a git bisect to locate the issue quicker:
1. Initial setup:
# Clone the git repository:
git clone git://git.freedesktop.org/git/poppler/poppler
# Get the 0.19.0 release (first known revision containing the issue):
git checkout poppler-0.19.0
# Start the bisect
git bisect start
# Inform git that poppler-0.19.0 has the issue
git bisect bad
# Get the 0.18.4 release (first known revision not containing the issue):
git checkout poppler-0.18.4
# Inform git that poppler-0.18.4 does not have the issue
git bisect good
2. Build the current revision:
# Clean the poppler directory of build files
git clean -fxd
# Build poppler
../autogen
../configure
make
# Run your test using the built poppler
....
# If the revision contains the bug, run:
git bisect bad
# ... and go back to step 2
# If the revision does not contain the bug, run:
git bisect good
# ... and go back to step 2
# If the bisect has finished, that commit is the problem commit
# Note the sha1 of the commit and go to step 3
export BAD_COMMIT=<sha1 of commit bisect reports>
3. Verify that reverting the commit fixes the issue
# Stop the bisect operation
git bisect reset
# Go to the master (main) branch
git checkout master
# Clean the poppler directory of build files
git clean -fxd
# Build poppler
../autogen
../configure
make
# Run your test using the built poppler (should fail)
....
# Revert the bad commit
git revert ${BAD_COMMIT}
# Clean the poppler directory of build files
git clean -fxd
# Build poppler
../autogen
../configure
make
# Run your test using the built poppler (should pass)
....
4. Report the bad commit
# Get the bad commit
git show ${BAD_COMMIT} > bad-commit.diff
# View the bad commit
cat bad-commit.diff
Thanks,
- Reece
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
poppler mailing list
<a class="moz-txt-link-abbreviated" href="mailto:poppler@lists.freedesktop.org">poppler@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/poppler">http://lists.freedesktop.org/mailman/listinfo/poppler</a>
..
</pre>
</blockquote>
<br>
</body>
</html>