Issue 123478 - CRASH when applying lots of color properties changes to greyscale raster graphics
Summary: CRASH when applying lots of color properties changes to greyscale raster grap...
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: editing (show other issues)
Version: 4.0.1
Hardware: PC Windows 7
: P3 Critical (vote)
Target Milestone: 4.1.0
Assignee: Armin Le Grand
QA Contact:
URL:
Keywords: crash, regression, release_blocker
Depends on:
Blocks:
 
Reported: 2013-10-15 03:16 UTC by Rainer Bielefeld
Modified: 2014-04-03 06:35 UTC (History)
5 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2013-10-15 03:16:33 UTC
Steps how to reproduce Reproducible with "AOO 4.0.1   – German UI / German locale  [Rev. 1524958 2013-09-20 11:40:29]" on  German WIN7 Home Premium (64bit)", “historic”  4.0  User Profile used for all  predecessor versions:

Simply a document similar  <http://www.bielefeldundbuss.de/OOO_QA/sample20.odg>
For me these documents crash 3 times per hour or so, currently I can not see any common root for the crashes, I will have to learn how to create a crash report. Currently OOo is not usable for me for these documents.
Comment 1 Rainer Bielefeld 2013-10-15 06:47:00 UTC
A first test result is that also LibO 4.2-dev is affected.
Comment 2 Prosper Uniger 2013-10-15 12:18:26 UTC
steps to reproduce:
* open file from comment 0
* select graphic on first page
* goto property pane -> color -> set cursor in contrast field
* press key up (repeatedly fast or keep it down)
-> memory consumption rises fast (120MB to 1400MB) -> crash

this works with other changes too like brightness
you just have to do it fast i guess

btw: no excessive memory consumption in AOO 3.4.1
Comment 3 Rainer Bielefeld 2013-10-15 12:44:31 UTC
(a) I opened the sample document directly clicking the link in the report with AOO 4.0.1 WIN7 and  tried as Prosper Uniger. No crash following his hints exactly, but I got a crash when I first increased contrast 0 -> 100 % by permanent uparrow button in spinbox, then 100 -> 0% by permanent downarrow button, then wild gambling with all spinbuttons. Afer 20s or so AOO crashed. The Recovery Message appeared for me and an additional "Saving Documents" Message with progress bar, but no progress visible.  1 soffice.exe task remained active, I had to kill them in Task manager. 

(b) I never did something similar like Prosper Uniger describes, but my suspect is that I get those crashes when I do many quick actions, so my crash root might be similar to Prosper Uniger's. I think we will get some similar ways how to get the crash.

(c) And I can confirm the observation with the significant increase of memory consumption doing quick actions, I will watch that possible root.

(d) CONFIRMED for now, although I think we still need some research here
Comment 4 Rainer Bielefeld 2013-10-15 13:35:23 UTC
permanent dragging of the spinbox buttons does not crash for me, but 5 clicks per second reach the crash reliably. Also crashes with transparency and other picture properties.

It seems not to be a general picture, but something with black/white or greyscale pictures. Steps how to reproduce with "AOO 4.0.1   – German UI / German locale  [Rev. 1524958 2013-09-20 11:40:29]" on  German WIN7 Home Premium (64bit)", “historic”  4.0  User Profile used for all  predecessor versions:

0. Start WIN Task Manager, Performance view with Memory chart line
1. Do screenshot of your Desktop
2. Copy to new blank IrfanView document
3. IrfanView: Edit -> Copy
4. From AOO Start Center open blank new Draw document 
5. Paste
   > Screenshot appears
6. Do proceeding to provoke a crash (select picture, lots of increase contrast 
   spin button clicks
   Nothing unusual happens, no significant increase of memory consumption

New Test all the same, but in a step 2.1 after 2 in IrfanView Menu 'Picture ->
Change to greyscale'.

After a minute or so I get the CRASH

Sorry, I used "Calc" accidentally.
Comment 5 Prosper Uniger 2013-10-15 14:32:34 UTC
(In reply to Rainer Bielefeld from comment #4)
I don't know what you mean by raster picture but I can confirm this:
* paste a screenshot (taken by ATL + Print or ALT Gr + Print) in a new draw document
* change color mode to greyscale or black/white (property pane)

now every change I make increases the memory consumption of soffice.bin by a few megabyte
even simple dragging or repeated undo + redo

looks like the crash is only a symptom of huge a memory leak


I'm working on a 32bit Vista and probably got less memory than Rainer so I crash earlier.
Comment 6 Rainer Bielefeld 2013-10-15 16:46:04 UTC
I will try to find a relation to my crashes I observe. I definitively do no intended edits with the foreground pictures (generally I have them on a locked layer), but it might be that there are some strange interactions what also cause this crash without editing the pictures.

Or I will have to submit a separate Bug for my problem when my investigations will have found a different root.

@Prosper Uniger:
<http://en.wikipedia.org/wiki/Raster_graphics>. Although "bitmap" is more common, I avoid that word because it can be confused with .bmp
Comment 7 Rainer Bielefeld 2013-10-16 06:24:30 UTC
Printing to FreePDF and normal printers of the sample document (mentioned in original report) also shows the characteristic quick increasing memory consumption. Similar documents with some more pages will cause a crash on my PC. I am pretty sure that that problem is related.
Comment 8 Rainer Bielefeld 2013-10-17 04:44:30 UTC
I did some additional tests with sample document from original report.

(e) Already Reproducible with  "AOO 4.1.0-Dev – English  UI / German locale - [AOO410m1(Build:9750)  -  Rev. 1521488 - 2013-09-11]" on German WIN7 Home
Premium (64bit)", own separate user profile

(f) was still ok for contrast spinbox changes and printing 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. But with that version reaction to a spin button click is very retarded (Bug 122923 ?)

(g) Still reproducible with  "AOO 4.1.0-Dev – English  UI / German locale - [AOO410m1(Build:9750)  -  Rev. 1530680 - 2013-10-11]" on German WIN7 Home
Premium (64bit)", own separate user profile. (Because of incomplete LCo selector (Bug 123063) no correct information can be left)

(h) My suspect: Fix for "Bug 122923 - Bad performance showing ODF with page size foreground pictures" causes the big memory consumption?
Comment 9 Prosper Uniger 2013-10-17 10:18:09 UTC
I did some tests with other AOO components
always the same steps:
a) new document
b) make screenshot and paste into the document
c) change values for
   - brightness
   - contrast
   - transparency
   and watch memory consuption
d) change graphic to greyscale
repeat c)

results:
it only shows with greyscale or black/white, never with default or watermark

draw and impress - incresing memory consuption and crash
word - no effect with brightness or contrast, but incresing memory consuption and crash by changing transparency
calc - not affected
base - not tested but bug could apply to forms editor
math - does not apply, no graphics
Comment 10 Armin Le Grand 2013-10-21 10:09:46 UTC
ALG: Taking a look...
Comment 11 Armin Le Grand 2013-10-21 10:15:49 UTC
ALG: This is so unbelievable, I am shocked myself; I use an temporarily instance of BitmapBuffer when creating a GDI+ Bitmap object to get to 24bit color depth. That class gets filled by calling StretchAndConvert, filling the allocated memory with the 24bit temporary data. After using it, it gets deleted.
But: A look at the class BitmapBuffer shows:

					BitmapBuffer(){}
					~BitmapBuffer() {}

ARGH! It does neither initialize nor cleanup the memory that struct is administrating (!). Sorry, I did not control the implementation of that struct, it is actively used in VCL. I hate that old stuff, this means that all usages of that struct in the current code have to and do manage that memory handish. ARGH! Who did stuff like that?

To fix, I cannot even safely add a free memory to the constructor, this would require to identify all places where that memory is controlled handish; to safely fix this I will also have to free the mem controlled by that struct by hand...
Comment 12 Armin Le Grand 2013-10-21 10:32:09 UTC
ALG: Added, checked and works as expected. Luckily, this only happens when forcing to gray/B&W or with 8bit bitmaps added and on windows only, too. Still, a bad memory leak and a candidate when we may do another service release. Adding release_blocker keyword, too. Preparing commit...
Comment 13 Armin Le Grand 2013-10-21 10:42:16 UTC
ALG: Comitted, done. Also added to branch sysdepgs where I already migrated the GDI+ stuff to a more central place.
Comment 14 Rainer Bielefeld 2013-10-23 04:47:13 UTC
All problems listed here have vanished with  "AOO 4.1.0-Dev – English  UI / German locale - [AOO410m1(Build:9750)  -  Rev. 1534248 - 2013-10-22]" on German WIN7 Home Premium (64bit)", own separate user profile.
Comment 15 SVN Robot 2013-10-29 08:14:13 UTC
"alg" committed SVN revision 1534084 into trunk:
i123478 Secure mem freeing for BitmapBuffer class
svnbz message delay caused by perl problems after Bugzilla 4.4.1 update
Comment 16 SVN Robot 2013-10-29 08:14:28 UTC
"alg" committed SVN revision 1534084 into trunk:
i123478 Secure mem freeing for BitmapBuffer class
svnbz message delay caused by perl problems after Bugzilla 4.4.1 update
Comment 17 SVN Robot 2013-10-29 08:14:40 UTC
"alg" committed SVN revision 1534085 into branches/alg/sysdepgs:
i123478 Secure mem freeing for BitmapBuffer class
svnbz message delay caused by perl problems after Bugzilla 4.4.1 update
Comment 18 SVN Robot 2013-10-29 08:14:45 UTC
"alg" committed SVN revision 1534084 into trunk:
i123478 Secure mem freeing for BitmapBuffer class
svnbz message delay caused by perl problems after Bugzilla 4.4.1 update
Comment 19 Clarence GUO 2014-04-03 06:35:04 UTC
Verified on trunk build rev. 1582712, fixed.
ENV: Win7 64 bit professional SP1