Issue 123690 - CRASH when decreasing color picker vertical size too much
Summary: CRASH when decreasing color picker vertical size too much
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: 4.0.0
Hardware: All All
: P3 Major (vote)
Target Milestone: 4.1.0
Assignee: Armin Le Grand
QA Contact: Clarence GUO
Keywords: crash, regression
: 124226 124662 (view as issue list)
Depends on:
Reported: 2013-11-14 23:01 UTC by Josh Pharis
Modified: 2017-05-20 10:35 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.1.0-dev
Developer Difficulty: ---

patch to solve the crash (3.26 KB, patch)
2014-01-15 08:15 UTC, Oliver-Rainer Wittmann
orw: review?
Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Josh Pharis 2013-11-14 23:01:51 UTC
When resizing color picker drop-down, if the drop-down is made too small, Writer crashes. The size is dependent only on the vertical size. The horizontal size can be pushed to as small as it can go and it does not crash. But regardless of the horizontal size, when the vertical size is pushed to approximately when the blocks are too small to show the color, the program crashes.
Comment 1 Josh Pharis 2013-11-14 23:03:11 UTC
I was able to replicate this issue using Apple iMac:
AOO 4.0.0 [AOO400m3(Build:9702)  -  Rev. 1503704 2013-07-16 14:52:30 (Tues, 16 July 2013)] on iMac Mac OSX 10.6.8 Snow Leopard.
Comment 2 Nate 2013-11-15 01:08:47 UTC
Nate Q. 11/14/2013
I was able to replicate this crash on Mac OS X 10.9 Build 13A603 using Open Office 4.0.1. The bug is not exclusive to writer and I was able to reproduce the same crash in every application where a color picker is used.
To recreate the bug, I used any one of the font color, highlighting, or background color drop downs and resized the window vertically until the application crashed.
Comment 3 Oliver Brinzing 2013-11-15 08:12:57 UTC
confirming crash with aoo401 on winxp
Comment 4 Rainer Bielefeld 2013-11-16 18:38:47 UTC
Reproducible with server installation of "AOO 4.1.0-Dev – English  UI / English locale - [AOO410m1(Build:9750)  -  Rev. 1537973 - 2013-11-03]" on German WIN7 Home Premium (64bit)", own separate user profile:

1. From AOO start center open blank new Calc document using New Document icon
2. Long click on Character color icon in Standard Toolbar
   Color Picker appears
3. Move mouse pointer to bottom of dialog
   > Mouse pointer view changes to "resize"
4. Press left mouse button and move bottom dialog border upwards
   (3mm / s)
  CRASH when height becomes very small

Additional info:

(a) already  Reproducible with server installation of  "AOO 4.0.0-Dev – English UI / German locale [AOO400m1(Build:9700) – Rev.1476029  ((2013-04-26))]" on German WIN7 Home Premium (64bit)", own separate user profile

(b) was still ok (simply all contents of picker disappears) with server installation of  " AOO 4.0.0-Dev  – English UI / German locale [AOO400m1(Build:9700) - Rev. 1457992 – Rev.1457606  ((2013-03-19))]" on German WIN7 Home Premium (64bit)", own separate user profile

(c) Latest confirmation for AOO 4.1.0-dev, but because of incomplete LCo 
    selector (Bug 123063) no correct information can be contributed.
Comment 5 Oliver-Rainer Wittmann 2014-01-14 13:26:06 UTC
confirming the crash - works in AOO 3.4.1, broken in AOO 4.0.0
Comment 6 Oliver-Rainer Wittmann 2014-01-14 14:53:21 UTC
taking over to work on a solution
Comment 7 Oliver-Rainer Wittmann 2014-01-15 08:15:41 UTC
Created attachment 82282 [details]
patch to solve the crash

The crash is triggered by method <createBlendFrame(..)> by calling <BitmapWriteAccess::SetPixel(..)> with inappropriate value for <y>.
Due to the given comments regarding the values of <x> and <y> I identified the root cause: in case that <nH == 1> given statement <y == nH - 1> is not hold.

@Armin: As you are the author of method 
BitmapEx createBlendFrame( const Size&, sal_uInt8, Color, Color, Color, Color )
I asking you for a review of the proposed patch.
Comment 8 Oliver-Rainer Wittmann 2014-01-15 08:36:54 UTC
Comment on attachment 82282 [details]
patch to solve the crash

wrong flag ;-) - the "+" should be given by the reviewer
Comment 9 Armin Le Grand 2014-01-15 15:22:01 UTC
ALG: Thanks for checking. Indeed, when nW and/or nH are 1, x and/or y can be 1, too, after the loops. This is about blending a frame on a bitmap, thus these cases represent a target bitmap with no right/bottom line to be set. Representing that in the method...
Comment 10 Armin Le Grand 2014-01-15 15:26:53 UTC
Adapted and checked, this could indeed happen for X and Y, but for X the probability to destroy something with the write access is much less due to the mem structure of bitmaps. Both are now prevented, stepped through both extremes. Grepping, preparing checkin...
Comment 11 Armin Le Grand 2014-01-15 15:28:34 UTC
Okay, done. Thanks for finding this!
Comment 12 SVN Robot 2014-01-15 15:30:43 UTC
"alg" committed SVN revision 1558424 into trunk:
i123690 handle the extremes Width or Height equal one
Comment 13 Rainer Bielefeld 2014-02-13 06:39:10 UTC
*** Issue 124226 has been marked as a duplicate of this issue. ***
Comment 14 Clarence GUO 2014-02-26 02:38:52 UTC
Verified on snapshot Rev.1566593, the defect was resolved.
Comment 15 fanyuzhen 2014-02-27 01:58:54 UTC
Change defect status per Clarence Guo's comment
Comment 16 zhaoshzh 2014-04-01 06:56:57 UTC
Verified on snapshot Rev.1573601, the defect was resolved.
Comment 17 Ariel Constenla-Haile 2014-04-11 18:43:19 UTC
*** Issue 124662 has been marked as a duplicate of this issue. ***