[poppler] Bogus memory allocation size

[suzuki toshiya]

Dear Thomas,

Oh, thanks. There was a midair collision :-)

Regards,
mpsuzuki

Thomas Freitag wrote:
> Dear mpsuzuki!
> 
> 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:
> 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.
> 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:
> 
>   if (mat[2] >= 0) {
>     t0 = imgCoordMungeUpper(mat[2] + mat[4]) - imgCoordMungeLower(mat[4]);
>     if (splashAbs(mat[1]) >= 1) {
>       th = imgCoordMungeUpper(mat[2]) - imgCoordMungeLower(mat[0] * 
> mat[3] / mat[1]);
>       if (th > t0 && *th < 10000*) t0 = th;
>     }
>   } else {
>     t0 = imgCoordMungeUpper(mat[4]) - imgCoordMungeLower(mat[2] + mat[4]);
>     if (splashAbs(mat[1]) >= 1) {
>       th = imgCoordMungeUpper(mat[0] * mat[3] / mat[1]) - 
> imgCoordMungeLower(mat[2]);
>       if (th > t0 && *th < 10000*) t0 = th;
>     }
>   }
>   if (mat[3] >= 0) {
>     t1 = imgCoordMungeUpper(mat[3] + mat[5]) - imgCoordMungeLower(mat[5]);
>     if (splashAbs(mat[0]) >= 1) {
>       th = imgCoordMungeUpper(mat[3]) - imgCoordMungeLower(mat[1] * 
> mat[2] / mat[0]);
>       if (th > t1 && *th < 10000*) t1 = th;
>     }
>   } else {
>     t1 = imgCoordMungeUpper(mat[5]) - imgCoordMungeLower(mat[3] + mat[5]);
>     if (splashAbs(mat[0]) >= 1) {
>       th = imgCoordMungeUpper(mat[1] * mat[2] / mat[0]) - 
> imgCoordMungeLower(mat[3]);
>       if (th > t1 && *th < 10000*) t1 = th;
>     }
>   }
>   scaledHeight = t0 > t1 ? t0 : t1;
> 
> Cheers,
> Thomas
> 
> Am 05.05.2012 09:48, schrieb suzuki toshiya:
>> 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<aacid at kde.org>
>> 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:
>>> On 5 May 2012 08:13, suzuki toshiya<mpsuzuki at hiroshima-u.ac.jp>  wrote:
>>>> 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.
>>> 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
>> _______________________________________________
>> poppler mailing list
>> poppler at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>
>> .
>>
> 
>