Hi, wanted to load and save this Excel-presentation: http://www.statistik.tu-dortmund.de/~fried/RobusteVerfahren/0-Einleitung.pps and LO crashes as soon as I want to save it as LO-presentation.
I can confirm crash with LO 4.3.4, win7. I can confirm crash Version: 4.5.0.0.alpha0+ Build ID: 31e8084fc07c3de09230c0f0c6ed947b3de98df1 TinderBox: Win-x86@42, Branch:master, Time: 2014-12-07_06:59:33 Can not reproduce on Linux.
Created attachment 118766 [details] problematic document This issue is still present in Version: 5.0.1.2 Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: es-ES (es_ES) on Windows 7 (64-bit)
If someone still reproduces it on Windows with last stable LO version 5.0.3, any chance for a bt?
I opened the comment#2 file then a slideshow started automatically. I manually quit the slideshow then the show ended and after a while, Impress was killed automatically. It's not my expected result. My dev build: Version: 5.4.0.0.alpha0+ Build ID: f35d29c8388744be1f95ec4acfca12eec706911a CPU Threads: 2; OS Version: Linux 4.9; UI Render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group
(In reply to fiftyigfuci_f_mi from comment #4) > I opened the comment#2 file then a slideshow started automatically. > I manually quit the slideshow then the show ended and after a while, Impress > was killed automatically. >... It could be interesting to retrieve a bt (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace). Indeed, it might be a dup of tdf#105188
The crash report was successfully uploaded. crashreport.libreoffice.org/stats/crash_details/17b8cefb-de2f-4bd7-bcf3-4d741ca24cb2 Filed at least for Bug 105118 and Bug 105376.
*** Bug 105376 has been marked as a duplicate of this bug. ***
Similar reports (a lot!): http://crashreport.libreoffice.org/stats/signature/SalFrame::SetCallback%28vcl::Window%20*,bool%20%28*%29%28vcl::Window%20*,SalEvent,void%20const%20*%29%29
(In reply to Timur from comment #8) > Similar reports (a lot!): > http://crashreport.libreoffice.org/stats/signature/SalFrame:: > SetCallback%28vcl::Window%20*,bool%20%28*%29%28vcl::Window%20*,SalEvent, > void%20const%20*%29%29 Raising severity and priority! Thanks for triaging this.
Crash repro with 4.1, not with 4.0.5 (although it was slow) for attachment 118766 [details]. I'll mark as regression so far. I didn't test Stefan's attachment 130483 [details] and steps from Bug 105376 nor Bug 105118.
Because of the hint to Bug 105118 (GDI problem) I have made new tests with the spreadsheet document "Test_Comment_Crash.ods" attached to Bug 105376. Result: I think that the first "Save" or "Autosave" creates very much GDI objects. First I have increased the GDI quote in Windows from 10000 to 60000 to prevent the crashes (and reatarted the system to activate the change). A new test with my document gave no crash (but after document was saved and LO should be closed, shutdwon of LO was hanging - see bug 105055). Then I have "installed" Nirsoft GDIView to see the GDI objects counter at further tests. The counters I have seen at the several tests were not exactly the same, but they were in the same ranges always. The figures below are from one of the tests. When the document was opened and I had navigated to the first sheet ("Altix I bis III") the GDI counter ("All GDI") was 125. After the four first comments were inserted and before the document was saved the GDI counter was 255. This means that every comment has increased the counter by 27 or 28, although the comments are hidden. I don't if this correct or not. Because the comments are not shown I think only the bitmanp counter should be increased by 1. While the document was saved the GDI counter has extremly increased from 255 to 9873!!! After some additional comments have been inserted the old limit of 10.000 was exceeded. Interestingly: - Only at the first save (or maybe also Autosave) the GDI counter increases extremly. At additional saves the counter has not increased or increased only slightly. - At "Undo" the GDI counter does not decrease and at "Redo" it does not increase. These tests were made with LO 5.3.0.2 (x64).
I've tested this with a build that contains fix for Bug 103927, and I can't reproduce the crash.
Created attachment 130689 [details] debug from procdump dump Confirm. No crash and saving as before, slow. I'd kindly ask Stefan to test all those before closing. But, I get dump with procdump with error cppu3.dll!uno_type_equalData. Should that be considered the same bug?
(In reply to Timur from comment #13) > Created attachment 130689 [details] > debug from procdump dump > > Confirm. No crash and saving as before, slow. > I'd kindly ask Stefan to test all those before closing. > But, I get dump with procdump with error cppu3.dll!uno_type_equalData. > Should that be considered the same bug? No. I'd treat that as a different issue.
Test with Version: 5.4.0.0.alpha0+ Build ID: b41186a2fc49e440890b8c86e5367352ffaf9cd6 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-01-26_01:50:40 Locale: de-DE (de_DE); Calc: group First I have tested only the duplicate Bug 105376: Result: No crashes, GDI counter increases only slightly while file was saved. OK! But I have seen in GDIView, that GDI counter fast increases when sheet is edited. First I have thougt that this is related to insert of comments. But then I have seen that GDI counter also increases when cells ar selected by mouse click and also only by scrolling in the document. Finally it exceeds the limit and LO crashes. See also Comment 13 in Bug 102688! After this I have tried to open at the same time the attached documents from Bug 102688 (2x ods), from Bug 105118 (foo.odp) and from Bug 87204 (0-Einleitung.pps). Depending on the sequence how documents were opened there were several problems. I have not analized completely until now.
Caolán/Khaled: thought you might be interested in this one since gdi is related to fonts rendering (not only) so vcl part.
There is lots of duplicate communication going on here. I'll close this as duplicate. *** This bug has been marked as a duplicate of bug 102688 ***