https://bugs.documentfoundation.org/show_bug.cgi?id=95481
Armin Le Grand <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED QA Contact| |[email protected] --- Comment #13 from Armin Le Grand <[email protected]> --- Reproduced on linux. Reason is that LinearScaleContext::blendBitmap24 causes out-of-bound accesses to BitmapReadAccess/BitmapWriteAccess for extreme cases. It starts with OutputDevice::DrawDeviceAlphaBitmap which on linux may use OutputDevice::DrawDeviceAlphaBitmapSlowPath (on win and mac not used, so no crash there). blendBitmap24 in the case of a one pixel source use the correct index, but always uses tne next scanline to blend with it (pLine1). In case of a one pixel bitmap that does not exist. To avoid that a lot of strategies may be used e.g. to not mix with the next line at all or setup one more index in all cases or similar. Since it is a corner case (not often, fast) I opt for just using the initial scanline twice when there is no second, this will do no harm to blending, too. Tried that, works as expected. Doing more experiments how this coud be solved better -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
