[poppler] Bogus memory allocation size

[Thomas Freitag]

Am 05.05.2012 10:19, schrieb 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.
As far as I understand the intention of xpdf 3.0.3 and what we need for
rotated images the above quick and dirty solution seems to be
sufficient. But I've to create a correct patch and regtest it, therefore
I opened a bug https://bugs.freedesktop.org/show_bug.cgi?id=49523.
I will do it as quick as possible, suspending my actual work on bug
37347, because I think this bug is critical in respect of the planned
release date of 0.20.

Cheers,
Thomas
>> 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
>>>
>>> .
>>>
>>
>
> .
>