This bug was filed from the crash reporting server and is br-236f2a8b-8303-4876-9aac-d06932dcd3e7. ========================================= Moving an image around on a slide
Hello Peter, Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
This is once again an out of GDI handles crash. I thought we fixed that issue for 5.3.1.2 but apparently we still see these issues in 5.3.2.2
Peter - we're really eager to get some reproduction steps for this - since it is the most frequently reported issue type =) can you provide some more details on how this happened ? Thanks !
I have tried on a couple of occasions to unsuccessfully reproduce this. Unfortunately I didn't save the recovery file, sorry.
Hi Peter, Do you remember if at the time the crash happened you had many fonts installed in your system?
I have subsequently reproduced another crash. This time it silently died, no crash report. I will send you two files offline, I am not prepared to share them with the world and sanitising them may strip out info you are looking for. The only fonts that are non standard are Heuristica and Fira Sans
(In reply to Peter Beurle from comment #6) > I have subsequently reproduced another crash. This time it silently died, no > crash report. I will send you two files offline, I am not prepared to share > them with the world and sanitising them may strip out info you are looking > for. > > The only fonts that are non standard are Heuristica and Fira Sans Hi Peter, Yes, please. You can send the files to me and I can take a look. Regards
Issue reproduced in Versión: 5.3.2.2 Id. de compilación: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 Subproc. CPU: 1; SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; Configuración regional: ro-RO (es_ES); Calc: group and Version: 5.4.0.0.alpha1+ Build ID: 9d320ec4d818f86e58a15fd46248026502b1cc94 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-09_01:27:12 Locale: es-ES (es_ES); Calc: grou
Created attachment 133258 [details] sample File shared by Peter and minimized by me. Using GDIView, I found that LibreOffice leaks when the file is opened, the OLE objects in the file are copied/pasted or dragged/dropped and when the file is saved, however, it not always crashes, sometimes it just freezes when 10.000 objects are reached. For the time being, I found a couple of ways to reproduce the crash: 1. Reduce the limit of GDI objects as explained here: https://msdn.microsoft.com/es-es/library/windows/desktop/ms724291(v=vs.85).aspx and play around with the document copying or dragging things around. 2. Make three new copies of the document in your disk and open them one after the other with LibreOffice. LibreOffice will crash when the 10.000 limit is reached
Ok, I got a DrMemory log with Version: 5.4.0.0.alpha1+ Build ID: 970b431f1a7b6b96c4c9536657ce4fe9d8f5b585 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-11_23:07:53 Locale: es-ES (es_ES); Calc: group and this is the crashreport: crashreport.libreoffice.org/stats/crash_details/735862df-fd8b-4c10-b706-2fcd5361a5e0 Steps to reproduce: 1. Reduce GDI limits to 5000 2. Restart the OS 3. Open the attached document -> GDI objects go up to 4000 4. Copy one OLE object from the document and paste it many times until LibreOffice crashes. This is the first time I use DrMemory, so let me know if i'm uploading the correct log and if more traces are needed.
Created attachment 133260 [details] DrMemory log
Created attachment 133261 [details] sample2 Another way to reproduce the crash ( this time with a limit of 10.000 GDI objects). 1. Open sample2 2. Copy the 3 OLE objects 3. Paste them until LibreOffice crashes. You can just hold Crtl+V for a while until it crashes.
Hi Xisco - are you running drmemory on the soffice.exe (which is a trivial wrapper binary) - or on the soffice.bin (which needs renaming to soffice_real.exe or somesuch) ? =) The latter is really preferred. Sadly not much in the log. Also - I think we may require a patch to drmemory to dump where the gdi handlers were allocated from on exit - since we'll crash before they can be really 'leaked' - but then; perhaps exiting before we crash will show some leaks - although it could be that we just allocate way too many handles but don't per-se leak them =) Thanks !
Created attachment 133270 [details] DrMemory log ok, let's try again. Attaching 'results' file from DrMemory
The content of attachment 133260 [details] has been deleted
Created attachment 133291 [details] sample3 This file also crashes if the OLE object in it is copied/pasted many times. Steps: 1. Open the document 2. Copy the OLE object 3. Hold Ctrl+V until LibreOffice crashes
At first I could reproduce a leak when selecting/deselecting shapes. That leak went away over the weekend, thanks to this commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=289711c2a469bfbe06aef3b3870b65f9c788f56d author Markus Mohrhard <markus.mohrhard@googlemail.com> 2017-05-13 21:39:16 (GMT) committer Markus Mohrhard <markus.mohrhard@googlemail.com> 2017-05-13 22:27:09 (GMT) "fix gdi resource leak with unreleased virtual device" Now, copy/pasting the objects in attachment 133261 [details] (sample2) does increase DC count, so it's theoretically possible to reach the limit (I haven't tried), but deleting them reduces the count to the original value (~30).
Julien Nabet also did a couple of similar commits: 11c4cc15fdd491e15ffd4e7d9fb5d4082898f926 and 68a1cb23ede1d4ae6195850190fca6953c30417f However, it's still crashing while copying/pasting successively Tested in Version: 5.4.0.0.alpha1+ Build ID: 8c0be54a7da6262dffe04357121814dd22b5d7fe CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-15_01:35:45 Locale: es-ES (es_ES); Calc: group
Interestingly; can't reproduce the copy/paste GDI issue in OpenGL mode - which is interesting; in GDI mode as I copy/paste the embedded objects - I do get more and more handles allocated - but using 5.3.0.0.alpha0 (which I happen to have). Xisco - when you say 'many' times - are you talking several thousand ? ;-) if so, something of a corner-case methinks. Will trigger a new build on this machine to see what's up there though I guess.
> Xisco - when you say 'many' times - are you talking several thousand ? ;-) > if so, something of a corner-case methinks. Will trigger a new build on this > machine to see what's up there though I guess. So, the first time I open sample3 document, I have ~45 gdi objects, and if I copy paste the OLE object once, I have ~95, so it needs to be copied 200 times approximately. Indeed, it sound a bit like a corner-case, however, I think there might be other objects that create more GDI objects every time they're copied/pasted, and thus, easier to reproduce.
(In reply to Xisco Faulí from comment #20) > > Xisco - when you say 'many' times - are you talking several thousand ? ;-) > > if so, something of a corner-case methinks. Will trigger a new build on this > > machine to see what's up there though I guess. > > So, the first time I open sample3 document, I have ~45 gdi objects, and if I > copy paste the OLE object once, I have ~95, so it needs to be copied 200 > times approximately. Indeed, it sound a bit like a corner-case, however, I > think there might be other objects that create more GDI objects every time > they're copied/pasted, and thus, easier to reproduce. Xisco: could you give another try with a build including https://cgit.freedesktop.org/libreoffice/core/commit/?id=ba9b44270b56dfc6c416a55686d855a5b3c3c866 ? Indeed, searching in Opengrok about VirtualDevice, I stumbled upon this case. (as advised by Markus, I'll use with std::unique_ptr at this place later)
(In reply to Julien Nabet from comment #21) > (In reply to Xisco Faulí from comment #20) > > > Xisco - when you say 'many' times - are you talking several thousand ? ;-) > > > if so, something of a corner-case methinks. Will trigger a new build on this > > > machine to see what's up there though I guess. > > > > So, the first time I open sample3 document, I have ~45 gdi objects, and if I > > copy paste the OLE object once, I have ~95, so it needs to be copied 200 > > times approximately. Indeed, it sound a bit like a corner-case, however, I > > think there might be other objects that create more GDI objects every time > > they're copied/pasted, and thus, easier to reproduce. > > Xisco: could you give another try with a build including > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=ba9b44270b56dfc6c416a55686d855a5b3c3c866 > ? > Indeed, searching in Opengrok about VirtualDevice, I stumbled upon this case. > > (as advised by Markus, I'll use with std::unique_ptr at this place later) Hi Julien, it's still crashing in Version: 5.5.0.0.alpha0+ Build ID: 7662b11cad6105d56fb9acc9c431c89d3b68dc89 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-05-20_10:09:09 Locale: es-ES (es_ES); Calc: group
(In reply to Michael Meeks from comment #19) > Interestingly; can't reproduce the copy/paste GDI issue in OpenGL mode - > which is interesting; in GDI mode as I copy/paste the embedded objects - I > do get more and more handles allocated - but using 5.3.0.0.alpha0 (which I > happen to have). This also happens in OpenGL-mode (you are referring to LibreOffice->View->Graphics Output->Use OpenGL for all rendering, I assume). It is also not necessary to copy-paste. I frequently have this crash when just moving/resizing images (albeit with some copying or cut-pasting in-between). The system crashes very frequently. Three times today alone, and I definitely do not have to copy-paste 1k+ times. I noticed Impress gets quite slow to react before ultimately crashing, but that might be an unrelated performance issue.
It also just happend when done editing the content of a text field, with no other graphical effect active. I get the impression the problem occurs frequently when using a lot of inter-connecting elements like arrows. Doesn't seem inherently related to images. Just elements. Maybe they need a new GDI context each time they are changed, which would multiply with the number of connected arrows that also need updating in this case...
Wait, wrong. I was done editing, realized the box wasn't wide enough, and resized it to the left. kaboom
(In reply to stefan.elsen from comment #25) > Wait, wrong. I was done editing, realized the box wasn't wide enough, and > resized it to the left. kaboom Could you please try to reproduce it with LibreOffice 5.3.4 from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I haven't been able to reproduce this with 5.3.4
*** Bug 108303 has been marked as a duplicate of this bug. ***
It seems we don't have more reports from this crash since 5.3.4 -> http://crashreport.libreoffice.org/stats/signature/SalFrame::SetCallback(vcl::Window%20*,bool%20(*)(vcl::Window%20*,SalEvent,void%20const%20*)) I think it's save to close it... *** This bug has been marked as a duplicate of bug 106265 ***