This bug was filed from the crash reporting server and is br-37f400af-8df9-4540-b953-64770ed434d5. ========================================= Open libre office draw and click on any of the top menu items. Dropdown box appears and is empty. Use keyboard arrows to go up and down until crash is triggered.
Can you reproduce this crash? Could you get a screenshot of this: "Dropdown box appears and is empty" and attach here to this report? Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
Do you have this enabled: Tools - Options - LibO - View - Use OpenGL for all rendering? If yes, does the problem of empty dropdowns go away when you disable it?
When this originally occurred, I uninstalled 5.2 and installed 5.1 and it worked fine. After seeing your request, I uninstalled 5.1 and reinstalled 5.2 and the bug no longer occurs. After reinstalling 5.2, I verified "Tools - Options - LibreOffice - View - Use OpenGL for all rendering" and it was not checked. While I did not verify this option before uninstalling the original installation, I do not believe I had ever changed this from whatever the default was. Thank you for efforts. Please let me know if there is anything else you would like me to do, or any other information you would like me to provide, in order to help make this wonderful project more stable.
Hey, thanks for testing. I think we can set this to "works for me". If the problem ever comes back, we can revisit. If you want to help sometimes, you can check out this introduction to quality assurance: https://wiki.documentfoundation.org/QA/GetInvolved We have quite a good team, some do a little here and there, some do stuff more regularly. Yet, there is *always* work to do in the bug tracker. It is easy to step in and out of, because the tasks are bite-size.
Created attachment 129886 [details] Simulated screenshot showing appearance of empty menu.
Comment on attachment 129886 [details] Simulated screenshot showing appearance of empty menu. Am using LO 5.2.0.4 on a computer with fresh install of Windows 8.1. I had one monitor and LO worked as expected. Immediately after adding a second monitor, I experienced the problem described above. The menus disappear and are not clickable. In at least some cases I have been able to select a item from an open menu with a hot key, even though no items appear. This problem persists after closing and restarting LO. However, after crashing the program using the arrow keys as described, the menus will reappear at the next start. This has happened to me twice on successive days. If it happens again I will post a screenshot. http://crashreport.libreoffice.org/stats/crash_details/145beb54-e8aa-4924-91aa-543b15380c56
Created attachment 129899 [details] Actual screenshot Screenshot of the actual failure. Not sure why this only appears at the first run of the day. After the crash and report, LO seems to work well for the remainder of the day.
peklenk: please test with 5.2.4. Set to NEEDINFO. Change back NEW, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Several things: 1) Uninstall any LO version and install last stable one 5.2.4 as already requested 2) Use a brand new LO profile 3) Uncheck OpenGL for the test if it still crashes The 2 last steps are explained in detail here: https://wiki.documentfoundation.org/QA/FirstSteps
Reproduced. Steps taken: 1. Uninstall LibreOffice 5.3 2. Install LibreOffice 5.4 3. Delete %APPDATA%\LibreOffice 4. Restart computer 5. Open LibreOffice Here's the crash report: http://crashreport.libreoffice.org/stats/crash_details/aa98931f-c3e7-404f-a5c3-2ca6317d66b9 I was about to take a screenshot but it crashed.
As indicated, version field must correspond to the earliest one.
Caolan: thought you might be interested in this one (since vcl part) 2 weird things: 1) I wonder why menues are empty 2) in code source, function MenuFloatingWindow::ImplScroll, I noticed this: 604 if ( bScrollUp && bUp ) 605 { 606 nFirstEntry = pMenu->ImplGetPrevVisible( nFirstEntry ); 607 SAL_WARN_IF( nFirstEntry == ITEMPOS_INVALID, "vcl", "Scroll?!" ); 608 609 long nScrollEntryHeight = pMenu->GetItemList()->GetDataFromPos( nFirstEntry )->aSz.Height(); but in our case: 625 else if ( bScrollDown && !bUp ) 626 { 627 long nScrollEntryHeight = pMenu->GetItemList()->GetDataFromPos( nFirstEntry )->aSz.Height(); 628 629 nFirstEntry = pMenu->ImplGetNextVisible( nFirstEntry ); 630 SAL_WARN_IF( nFirstEntry == ITEMPOS_INVALID, "vcl", "Scroll?!" ); Shouldn't we mimic the first example so at least we might (I'm not sure since I don't reproduce this) avoid the crash? see http://opengrok.libreoffice.org/xref/core/vcl/source/window/menufloatingwindow.cxx#592 It's been like this since https://cgit.freedesktop.org/libreoffice/core/commit/?id=a61080c9bc96ca82f8416708792eca4a56623036 (2001-08-21)
(In reply to garfieldbanks from comment #10) > Reproduced. > > Steps taken: > 1. Uninstall LibreOffice 5.3 > 2. Install LibreOffice 5.4 > 3. Delete %APPDATA%\LibreOffice > 4. Restart computer > 5. Open LibreOffice > > Here's the crash report: > > http://crashreport.libreoffice.org/stats/crash_details/aa98931f-c3e7-404f- > a5c3-2ca6317d66b9 > > I was about to take a screenshot but it crashed. Instead of 5.3 and 5.4, I meant 5.2.3 and 5.2.4
garfieldbanks: just to complete information, could you confirm, you downloaded LO from TDF official website? (https://www.libreoffice.org/download/libreoffice-fresh/) Also what UI language do you use?
https://www.libreoffice.org/download/libreoffice-fresh type=win-x86_64 version=5.2 lang=en-US
https://www.libreoffice.org/download/libreoffice-fresh/?type=win-x86_64&version=5.2&lang=en-US
Clarification: Problem tested in Writer, Calc, Impress and happens in all 3. As mentioned it persists until the program is crashed, and then works for the rest of the day. en-US Steps taken: 1. Confirmed OpenGL is Default (not enabled). System uses onboard Intel HD graphics. 2. Uninstalled 5.2.0.4 (win x86) 3. Installed 5.2.4.2 (win x86) Problem has stopped since new install.
I wonder what this depends on exactly. Since there are still a few crash reports for this each day, I assume the bug is not fixed.
Aron Budea committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2aa43937ec9c9e22d9b28f4275a5bfb3ffbd82c0 tdf#104686: do not crash if Menu has been somehow disposed It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9fcb6cb86893b991ceb6395fbabba63c962f59db&h=libreoffice-5-3 tdf#104686: do not crash if Menu has been somehow disposed It will be available in 5.3.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Aron, Can this bug be closed as RESOLVED FIXED?
Apologies, unable to test fix; affected system has been decommissioned and erased after end of project.
All right, let's mark it as resolved, I'll keep an eye on the crash reports after 5.3.3.1 (available as pre-release in [1]). There's a chance menus could still turn up empty, as in attachment 129899 [details], feedback is welcome. [1] http://dev-builds.libreoffice.org/pre-releases/win/