Apache OpenOffice (AOO) Bugzilla – Issue 123478
CRASH when applying lots of color properties changes to greyscale raster graphics
Last modified: 2014-04-03 06:35:21 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.
A first test result is that also LibO 4.2-dev is affected.
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
(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
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.
(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.
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
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.
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?
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
ALG: Taking a look...
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...
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...
ALG: Comitted, done. Also added to branch sysdepgs where I already migrated the GDI+ stuff to a more central place.
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.
"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
"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
Verified on trunk build rev. 1582712, fixed. ENV: Win7 64 bit professional SP1