Situation: open Libreoffice document(s) and Outlook open.
1: when editing Outlook message (no attachments):
afer copy&paste, Outlook becomes very slow at times (e.g. cursor movement may take more than 10 seconds).
2: when editing Libreoffice document (not linked with Outlook):
LibreOffice becomes very slow, i.e. one types faster than LibreOffice can handle when entering text.
LibreOffice versions 3.6 and 4.0 (probably earlier as well)
Windows XP, Windows 7
case 1 can be reproduced on many machines, case 2 is not so common (so far one user reporting problem, but very consistently).
case 2: closing Outlook makes it worse; see bug 66539
correction: Outlook 2010
Slowness of Outlook also occurs when only the LibreOffice quickstarter is active and no documents are opened (neither the LibreOffice main screen is open).
Slowness does not occur once the quickstarter is closed.
Case 2 in comment #1 bothers now several users.
Currently we use :
LibreOffice version 4.1.5 and 4.2.2/4.2.3
MS Outlook 2010
Windows 7 professional, both 32- and 64 bit
"Slowness of Outlook also occurs when only the LibreOffice quickstarter is active"
Wow - what an interesting bug. Perhaps worth poking at some output from sysinterals (Microsoft's tracing package) - particularly the process explorer - to see what craziness is going on on the system ...
(In reply to comment #4)
> "Slowness of Outlook also occurs when only the LibreOffice quickstarter is
> Wow - what an interesting bug. Perhaps worth poking at some output from
> sysinterals (Microsoft's tracing package) - particularly the process
> explorer - to see what craziness is going on on the system ...
Could you give me some more clues on how to get that output?
(In reply to comment #5)
> > Wow - what an interesting bug. Perhaps worth poking at some output from
> > sysinterals (Microsoft's tracing package) - particularly the process
> > explorer - to see what craziness is going on on the system ...
> Could you give me some more clues on how to get that output?
Let me be a bit more specific:
I downloaded and ran Process Explorer from MS sysinternal suite.
With 2 calc and 1 writer document open (and Outlook),
I started a new email message, filled it with 5 lines (line 1, line 2, etc.)
I moved the caret up to line 3, selected lines 3 and 4 and did Ctrl-X, followed by down-key on keyboard.
The CPU-usage for the Outlook process jumped from 0.2 to 20-25% for some seconds and the caret only moved down after some seconds.
Repeating same sort of action gave similar results.
Repeating with LO documents closed and LO quickstarter loaded gave almost similar results (CPU percentage went to 18%).
Repeating with LO quickstarter closed gave CPU percentage below 1%.
I bet this is not the output you want, so please disclose me your wishes ;-)
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.
For more information about our NEEDINFO policy please read the wiki located here:
If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Problem still present in version 220.127.116.11.
@MMeeks: Could you expand on your suggestion to use the process explorer?
So - really no idea what's going on; I believe sysinternals has a file monitor app - if the problem goes via files we can use that to get a handle on what is going on there (perhaps).
Beyond that - you could attach windbg and try to reproduce the problem, and break inside LibreOffice when its consuming time and get a stack trace or two.
I assume that we see a chunk of CPU time coming from a soffice.bin process while the hanging is going on ? [ or is it all inside outlook? ].
Hard to know where to go here really short of replicating the setup.
I can reproduce the behaviour on all machines in our company, but process explorer and proces monitor from sysinternals just show an increase in CPU-% for Outlook (see comment #6, on some machines it rises to 40% for more than 4 seconds) and a huge number of process lines from OUTLOOK and other, possibly related processes (a.o. indexer, McAfee).
It may well be that a third application/process (with Outlook and LibreOffice being the 2 others) has a role in it. And as the problem is a delay when mving the caret in an Outlook message, I see no way to use windebug to catch something in LibreOffice.
Setting the status to unconfirmed and hoping that someone else experiences a likewise problem but has more clues.
Moving the caret - that's really odd. Of course it could be IAccessible - try disabling a11y [ if that's even possible anymore on windows - I think there is an environment variable for that though if you grok the code in vcl / winaccessibility ]. Then again, that wasn't present in 3.6.5 =)
It could be thumbnailing attachments (I guess) - if we do that.
It'd be interesting to know if sysinternals shows what is happening on the system when you move the caret: is a file saved (perhaps we're being used to thumbnail that or something ? ;-)
Created attachment 108882 [details]
logfile of processmonitor
Actions taken (Windows7, Outlook2010, LO4.2.7):
-open new Calc document (and minimize)
-open new E-Mail message
-cut some text (Ctrl-X) and move caret some lines down
-save processmonitor log
What looks strange to me is line 300, where soffice starts a thread. Why would that be?
It is not doable for me to time my actions with the lines in the log, the processmonitor makes me dizzy.
(In reply to Winfried Donkers from comment #12)
> Created attachment 108882 [details]
> logfile of processmonitor
BTW, a lot of processes are filtered out (svchost, wmiprvse. etc.)
Created attachment 109032 [details]
logfile(2) of processmonitor
same steps as yesterday.
Processexplorer shows cpu-activity of 40-50% for outlook.exe, no activity that's worth mentioning for soffice.
Loglines 110-120 seemed to coincide with the slowness -hard to be sure as the processmonitor 'freezes' at times and only later catches up-.
The activities from soffice don't seem to take much time.
A collaegue, who has the slowness the other way round (slow Writer when Outlook is open) is trying to catch some traces of that behaviour.
Nothing much in the processmonitor log. You sure it's not just memory pressure or something ? =) it sounds really unusual.
The machine I use for testing has sufficient memory (40% unused).
I feared that McAfee services could influence the behaviour, so I tested also with these services stopped: same behaviour.
With mcAfee services started again and calc closed (quickstarter still active) the outlook slowness was completely absent (i.e. I was stunned by the speed).
Created attachment 109333 [details]
logfile(3) of processmonitot
Taken from another machine experiencing slow Calc whilst Outlook was open.
type anything in a cell of a calc document
Outlook processor use rises to 25%, entering characters in calc is not visible (not processed by calc) for some seconds
Using the backspace key produces similar results.
The slowness could be reproduced for half an hour, then it disappeared.
(I've received similar reports with Writer instead of Calc, it's not module-specific.)
(In reply to Winfried Donkers from comment #10)
> I can reproduce the behaviour on all machines in our company,
(In reply to Winfried Donkers from comment #3)
> Case 2 in comment #1 bothers now several users.
So not a 1-machine fluke...
Status -> NEW
Surprise: With Outlook we use a small aaa-in (Advanced_security from MAPILabs) that allows other applications to create/send e-mails with Outlook without messages asking for permission.
Disabling this add-on ends the slowing down of Outlook and/or LibreOffice :-)
(That creates another problem here, but has nothing to do with LibreOffice).
Thank you all for your suggestions in finding the cause!
Phew ! thanks for the update, I've been idly fretting about this bug =) Good to know it's not our fault !