Description: Check for updates is an empty dialog box (and all menu's are empty afterwards) Steps to Reproduce: 1. Launch LibreOffice 2. Help -> Check for updates -> Empty box 3. Close it & expand a menu like file -> empty list Actual Results: Check for updates is an empty dialog Expected Results: Some text & and not affecting everything else Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.0.0.alpha0+ (x86) Build ID: c30ea50dd2b1c557dfbefc1a4c660fbf2402a604 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-06-04_22:59:40 Locale: it-IT (nl_NL); UI-Language: en-US Calc: threaded
don't repro in Version: 6.4.0.0.alpha0+ (x64) Build ID: c30ea50dd2b1c557dfbefc1a4c660fbf2402a604 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-05_00:23:26 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded win 7 problem?
(In reply to Roman Kuznetsov from comment #1) > win 7 problem? Could be x86 only.. didn't repro with x64 build (difference of a few day's) or a win 8.1 issue
I can't reproduce it in Version: 6.3.0.0.beta1+ (x86) Build ID: 5cfac16dbd4af456a7fb6d52c8953c69a72ba2ba CPU threads: 16; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded
Hi Telesto, Have you tested with a clean profile ?
Created attachment 151963 [details] Screenshot
(In reply to Xisco Faulí from comment #4) > Hi Telesto, > Have you tested with a clean profile ? Yes No repro with x64 Version: 6.4.0.0.alpha0+ (x64) Build ID: 95462a02a3aee1e3e7f9aa8fc50ba25fee3fa592 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-03_07:09:38 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Also with Versie: 6.3.0.0.alpha1 Build ID: 547edd20e527fb02900f6174973770d26306e2e7 CPU-threads: 4; Besturingssysteem: Windows 6.3; UI-render: standaard; VCL: win; Locale: nl-NL (nl_NL); UI-taal: nl-NL Calc: CL
Created attachment 152172 [details] Bibisect log Bisected to: author Jan-Marek Glogowski <glogow@fbihome.de> 2017-08-15 08:05:51 +0200 committer Jan-Marek Glogowski <glogow@fbihome.de> 2017-09-19 09:25:14 +0200 commit 3840aede596e6fc24f7ed7df9100fb028134aac6 (patch) tree 74d1d5efa3b2ad5448181fc185faf226aed192e4 parent 10b49dfb3996f99dec8dd0d2ffae2aef4022f395 (diff) Unify SolarMutex implementations All backends implement the SolarMutex in mostly the same way. So this consolidates this code into a GenericSolarMutex. We still need the abstract SolarMutex class for the fake AKA fascade implementation in dbaccess. The patch also replaces various places of direct mutex usage with either SolarMutexGuard or SolarMutexReleaser objects.
Created attachment 152173 [details] Bibisect log Sorry, second attempt. Bibisected the wrong thing the first time Bisected to author Jan-Marek Glogowski <glogow@fbihome.de> 2017-08-24 13:41:37 +0200 committer Jan-Marek Glogowski <glogow@fbihome.de> 2017-09-22 13:00:13 +0200 commit 448e9da1b440561441602e3a0956218b2702767e (patch) tree 4282d5093419247ffd8d2dc55af0ede3623ba6b2 parent 43fd2b2597ce7ac3307794c712e4d8e29e26db5c (diff) tdf#111994 WIN workaround PostMessage delays Fixes the "Multiple timers in queue" assertion by effectively removing it. When debugging it became obvious, that PostMessage returns, even if the message was not yet added to the message queue. The assert happens, because we start the timer in the Scheduler before Invoke(), so it fires, if we block in Invoke(), and then reset the timer after Invoke, if there were changes to the Task list. In this case it fires during Invoke(), the message is added. We restart the timer, first by stopping it (we wait in DeleteTimerQueueTimer, to be sure the timer function has either finished or was not run). And the try to remove the message with PeekMessageW, which doesn't remove the posted message. Then the timer is restarted, and when the event is processed, we end up with an additional timer event, which was asserted. As a fix this adds a (microsecond) timestamp to the timer message, which is validated in the WinProc function. So if we stop the timer too fast, the event is ignored based on the timestamp. And while at it, the patch moves timer related variables from SalData into WinSalTimer.
@Jan-Marek The update dialog/ menu dialogs are empty under certain circumstances.. I bi-bisected to: Jan-Marek Glogowski <glogow@fbihome.de> 2017-08-24 13:41:37 +0200 committer Jan-Marek Glogowski <glogow@fbihome.de> 2017-09-22 13:00:13 +0200 commit 448e9da1b440561441602e3a0956218b2702767e (patch) tree 4282d5093419247ffd8d2dc55af0ede3623ba6b2 parent 43fd2b2597ce7ac3307794c712e4d8e29e26db5c (diff) tdf#111994 WIN workaround PostMessage delays Fixes the "Multiple timers in queue" assertion by effectively removing it. However, it's apparently hard to reproduce for others for some unknown reason, however there are a few reports though. Note, the issue isn't limited to Update dialog.. does also happening 'randomly' while using LibO, mostly after some stressing, I guess.
Hi Telesto, is this issue still reproducible with a master build? Dialogs has been welded in recent versions, so it has might been fixed meanwhile...
No repro Versie: 6.4.0.2 (x86) Build ID: 08d19fecdc7a2298d051e19cfdb7c35544855fc3 CPU-threads: 4; Besturingssysteem: Windows 6.3 Build 9600; UI-render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-taal: nl-NL Calc: CL