Download it now!
Bug 75328 - Draw and Impress are slow to start on Windows platform
Summary: Draw and Impress are slow to start on Windows platform
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: Other Windows (All)
: medium normal
Assignee: Andrzej Hunt
URL:
Whiteboard: target:4.3.0 target:4.2.4
Keywords: regression
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2014-02-21 14:25 UTC by Gabriel Diosan
Modified: 2014-09-19 07:43 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Diosan 2014-02-21 14:25:38 UTC
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
Comment 1 tommy27 2014-02-22 06:59:46 UTC
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.
Comment 2 Gabriel Diosan 2014-02-22 13:02:00 UTC
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.
Comment 3 Gabriel Diosan 2014-02-22 13:03:26 UTC
I should add the version of Libreoffice in Ubuntu 14.04 at the moment is 4.2.0.4.
Comment 4 V Stuart Foote 2014-02-22 13:29:13 UTC
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?
Comment 5 Gabriel Diosan 2014-02-22 13:39:09 UTC
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?
Comment 6 tommy27 2014-02-22 14:57:59 UTC
(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
Comment 7 Michael Meeks 2014-03-13 19:49:02 UTC
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 (?) =)
Comment 8 V Stuart Foote 2014-03-13 20:58:21 UTC
@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
Comment 9 Andrzej Hunt 2014-03-18 07:18:58 UTC
The trouble seems to be in the DiscoveryService constructor which does socket setup on the main thread, should be trivial I think.
Comment 10 Commit Notification 2014-03-18 12:21:41 UTC
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.
Comment 11 Gabriel Diosan 2014-03-22 06:37:23 UTC
Thanks for looking into this Andrej.

Is there any chance of the bug fix being backported to Libreoffice 4.2?
Comment 12 Commit Notification 2014-03-24 11:05:44 UTC
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.
Comment 13 Gabriel Diosan 2014-03-24 13:28:48 UTC
(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.
Comment 14 helplibreoffice 2014-09-16 03:27:54 UTC
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.
Comment 15 Andrzej Hunt 2014-09-16 05:09:46 UTC
(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.)
Comment 16 helplibreoffice 2014-09-16 17:55:45 UTC
@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?
Comment 17 Andrzej Hunt 2014-09-19 07:43:51 UTC
(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.)