Problem description: Steps to reproduce: 1. Open Libreoffice Draw or Impress 2. Both applications take a considerable about of time to open. Current behavior: Libreoffice Draw and Impress are very slow to start. Expected behavior: Libreoffice Draw and Impress should start as quickly as Writer and Calc. I have tested this on a 32 bit Windows 7 Professional install. Launching Draw or Impress via the startcenter or directly still results in slow startup. Operating System: Windows 7 Version: 4.2.0.4 release Last worked in: 4.1.4.2 release
I confirm issue under Win7x64 using 4.2.0.4 cold LibO start --> click Draw or Impress icon in start screen --> wait 8 seconds to load (Writer, Calc, MAth and Base load in 1 second) moreover: cold LibO start --> click Draw (or Impress) icon in start screen --> wait 8 seconds to load --> close Draw --> click again on Draw icon in start screen --> wait 1 second to load so it's seems that only the first Draw or Impress launch consumes so much time, following launches from startscreen are fast as expecter. this behaviour is not present in 4.1.5.3 were all components load in 1 second from start screen. hence, REGRESSION. Linux and Mac testers are welcome to see if this issue is limited to Windows or not.
I have tested Libreoffice Draw and Impress on Ubuntu Gnome 14.04 (64bit) with the official Ubuntu packages and the problem does not appear to be present. In my testing on the Windows machine, Draw and Impress were slow to start all the time, not just on cold start.
I should add the version of Libreoffice in Ubuntu 14.04 at the moment is 4.2.0.4.
On Windows 7 sp1, 64-bit with full install of 4.2.1.1 Version: 4.2.1.1 Build ID: d7dbbd7842e6a58b0f521599204e827654e1fb8b On initial clean launch (i.e. with user profile renamed) launch of either Impress or Draw will attempt to establish a network connection that requests firewall exception. So what happens for you if any existing exception in Windows Advanced firewall is cleared of LibreOffice entries and you clear user profile. And then if on initial launch you cancel to deny the exception? For me launch times for either mode match those of the others (Writer, Calc, Math, Base). Similar if I deny public connections but allow private/work exceptions. So could this be simple network latency for you all? I guess I could throw 4.2.0.4 back on to test that specific release, but for now what happens if you adjust firewall for network activity in draw or impress?
I can't test the changes to firewall settings as the Windows machine I tested on was in a work environment and I 1. Don't have access to the backend infrastructure; and 2. I would not want to mess around with the firewall settings at work. :) Maybe someone else can confirm whether network latency is the problem?
(In reply to comment #4) > .... > > Similar if I deny public connections but allow private/work exceptions. So > could this be simple network latency for you all? > > ... I don't think that network latency is the cause... 4.1.5.3 launches fast on the same computer where 4.2.0.4 launches slow under the same conditions, so there's clearly a different behaviour between 4.1.x and 4.2.x. for the record 4.3.0.0.alpha0+ (*) is slow as well as 4.2.x (*) Build ID: ecf22894f522374cbdb8196d3bdef88e2fba7af9 TinderBox: Win-x86@39, Branch:master, Time: 2014-02-15_01:01:17
Any synchronous network connection on start sounds like a horrible bug to me =) It'd be wonderful to have a stack-trace for that - just attach the debugger and get a trace of all threads at that point (?) =)
@Michael, *, (In reply to comment #7) > Any synchronous network connection on start sounds like a horrible bug to me > =) It'd be wonderful to have a stack-trace for that - just attach the > debugger and get a trace of all threads at that point (?) =) Just verified on Windows 7 sp1, 64-bit with both todays TB39 build of master and TB42 build of 4.2.3 After normal /A administrative install, initial launch of either Impress or Draw will trigger network activity that gets stopped as originating from soffice.bin. To repeat, have to clear the LibreOfficeDev "Allowed progarms and features" from the Windows Firewall each launch attempt to see the Windows Firewall exception pop-up. Not a proper StackTrace (have to work out how to bypass the first chance exceptions with WinDbg in order to get one) but I pulled these from a ProcessExplorer properties with TB39 master and its symbols. These calls look kind of suspect to me ;-) sdlo.dll!?restoreDiscoverable@RemoteServer and sdlo.dll!?ensureDiscoverable@RemoteServer coupled with the winsock calls This from one of the threads in a Draw lauch hung at the Firewall exception: wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8 wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x42b ntdll.dll!RtlIsDosDeviceName_U+0x23a27 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!ZwWaitForSingleObject+0x15 mswsock.dll!MigrateWinsockConfiguration+0x52a6 WS2_32.dll!recvfrom+0x79 sdlo.dll!?restoreDiscoverable@RemoteServer@sd@@SAXXZ+0x652e sdlo.dll!?GetViewFrame@ViewShell@sd@@QBEPAVSfxViewFrame@@XZ+0x7fe8 sal3.dll!osl_setThreadTextEncoding+0x63 MSVCR110.dll!__get_tlsindex+0x61 MSVCR110.dll!__get_tlsindex+0x45 ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36 And this from one of the threds in a Presentation launch hung at the Firewall exception: wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8 wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x42b ntdll.dll!RtlIsDosDeviceName_U+0x23a27 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!ZwWaitForSingleObject+0x15 mswsock.dll!MigrateWinsockConfiguration+0x6455 sal3.dll!osl_acceptConnectionOnSocket+0xcb sal3.dll!sal_detail_log+0x10 sdlo.dll!?ensureDiscoverable@RemoteServer@sd@@SAXXZ+0x7a2 sal3.dll!osl_setThreadTextEncoding+0x63 MSVCR110.dll!__get_tlsindex+0x61 MSVCR110.dll!__get_tlsindex+0x45 ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36
The trouble seems to be in the DiscoveryService constructor which does socket setup on the main thread, should be trivial I think.
Andrzej Hunt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c0fb2640665d552b39deb2192d59fa11ea701d51 fdo#75328 Do DiscoveryService socket setup off the main thread. 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.
Thanks for looking into this Andrej. Is there any chance of the bug fix being backported to Libreoffice 4.2?
Andrzej Hunt committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=295c0c40682581215756e8bd744c8f2b04bd1acf&h=libreoffice-4-2 fdo#75328 Do DiscoveryService socket setup off the main thread. It will be available in LibreOffice 4.2.4. 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.
(In reply to comment #12) > Andrzej Hunt committed a patch related to this issue. > It has been pushed to "libreoffice-4-2": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=295c0c40682581215756e8bd744c8f2b04bd1acf&h=libreoffice-4-2 > > fdo#75328 Do DiscoveryService socket setup off the main thread. > > > It will be available in LibreOffice 4.2.4. > > 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. Thank you so Andrzej. Really appreciate you putting in the time to fix this.
I'm not sure if this information should be added to this bug or should be separate. It seems very related to this thread, so I'll add it here for now. If it should be separate, let me know and I can make it a separate item. I installed LO v4.3.1.2 on a client's WinXP system today. Before installing, I verified MD5 hash to ensure it was a valid download. Actual Behavior: Loading the LO launcher, Writer, and Calc worked as expected. Loading Draw and Impress resulted in firewall warnings. Expected Behavior: Loading Draw and Impress should not attempt to establish a connection via the internet without a dialog box from LO giving the option to enable or disable whatever feature is trying to access the internet. A full explanation of that feature, whatever it is, should be included. Steps to Reproduce: 1. Install LO on a machine that has never had LO installed. 2. Load the LO launcher application and turn off checking for updates. 3. Load Writer and Calc -> No Problems 4. Load Draw -> Firewall Warning 5. Load Impress -> Firewall Warning I went through the Options for Draw and Impress, and outside of checking for updates, I did not see any options to turn off features requiring an active connection to the internet. Is the above behavior by design? If so, I think it may be a good idea to change the design. I'm not sure how the status of the bugreport should be marked, so if someone else can change it as appropriate, that would be great.
(In reply to comment #14) > I'm not sure if this information should be added to this bug or should be > separate. > > It seems very related to this thread, so I'll add it here for now. If it > should be separate, let me know and I can make it a separate item. > > I installed LO v4.3.1.2 on a client's WinXP system today. Before > installing, I verified MD5 hash to ensure it was a valid download. > > Actual Behavior: Loading the LO launcher, Writer, and Calc worked as > expected. Loading Draw and Impress resulted in firewall warnings. > > Expected Behavior: Loading Draw and Impress should not attempt to establish > a connection via the internet without a dialog box from LO giving the option > to enable or disable whatever feature is trying to access the internet. A > full explanation of that feature, whatever it is, should be included. > > Steps to Reproduce: > 1. Install LO on a machine that has never had LO installed. > 2. Load the LO launcher application and turn off checking for updates. > 3. Load Writer and Calc -> No Problems > 4. Load Draw -> Firewall Warning > 5. Load Impress -> Firewall Warning > > I went through the Options for Draw and Impress, and outside of checking for > updates, I did not see any options to turn off features requiring an active > connection to the internet. > > Is the above behavior by design? If so, I think it may be a good idea to > change the design. > > I'm not sure how the status of the bugreport should be marked, so if someone > else can change it as appropriate, that would be great. That's bug 79847 (Draw/Impress AREN'T trying to connect to the internet, they're opening network sockets (for the local network) for the Impress Remote to work.)
@Andrzej: Thank you for the explanation and the link to the other bugreport. That report definitely describes the issue for Impress. Is Draw also opening a socket to look for the Impress remote, or is that a bug?
(In reply to comment #16) > @Andrzej: Thank you for the explanation and the link to the other bugreport. > That report definitely describes the issue for Impress. Is Draw also > opening a socket to look for the Impress remote, or is that a bug? Draw and Impress are essentially the same application (seen internally, in terms of the code/modules), i.e. it's the same thing. (Perhaps we could be more clever and start the impress remote only when opening Impress documents, but that would introduce a good chunk more complexity (i.e. more bugs likely) -- so I guess this could be considered as a separate bug, but tbh. highly unlikely to be considered a priority to fix.)