r2204 - Outlook 2003 causes processor to spike at 100%

[pmorris]

OS: Windows XP Service Pack 3
NVDA: trunk-r2204

Observed:
When the user opens a mail message in Outlook 2003 the processor peaks at 100% and NVDA has to be killed to recover system functionality.

The NVDA log does not appear to display any errors when this occurs.

Steps to Repro:
1. Install trunk-r2204
2. After installation, open Microsoft Outlook 2003
3. Select a mail message.
4. The mail message opens and NVDA announces the new Window taking focus.
4. Nothing then appears to happen and NVDA stops functioning.
5. If the user then opens the Windows Task Manager, the processor is spiked at 100%

[pmorris]

Additional: This appears to be a memory bleed. I monitored the Task Manager and it was over 100M of memory and climbing

[pmorris]

I closed out of Outlook and the following errors showed in the log:

ERROR - stderr (20:42:21):
Exception
ERROR - stderr (20:42:21):
exceptions
ERROR - stderr (20:42:21):
.
ERROR - stderr (20:42:21):
WindowsError?
ERROR - stderr (20:42:21):
:
ERROR - stderr (20:42:21):
'exception: access violation reading 0x00000000'
ERROR - stderr (20:42:21):

in

ERROR - stderr (20:42:21):
<bound method POINTER(IAccessible).del of <POINTER(IAccessible) ptr=0x199c54 at 20bec10>>
ERROR - stderr (20:42:21):

ignored

[jteh]

How big was the message you were trying to load? It is possible that this was not a crash, but rather, just the old virtual buffer code taking a very long time to load. This would explain the CPU spike. How long have you waited before killing NVDA?

Try loading a very small message.

[pmorris]

I tried this again with the latest snapshot (r2275).

I opened a plain text message that contained the text:
This is a test

This is a test.

NVDA failed to respond and read the message after 19 minutes - at which point I killed the process.

At 16 minutes elapsed NVDA was using 106mb of memory.
At 19 minutes elapsed NVDA was using 131MB of memory.

[vtsaran]

The problem with Outlook 2003 and text/HTML messages still persists. In looking at the log, it seems that MSHTML.py produces a call for an unknown attribute isContentEditable. After it fails, it seems like some events get stuck in the queue.
Here is couple of lines from the log:

INFO - appModuleHandler.update (14:02:13):
Loaded appModule outlook
ERROR - queueHandler.flushQueue (14:02:34):
Error in func _queueEventCallback from eventQueue
Traceback (most recent call last):

File "C:\Documents and Settings\vtsaran\My Documents\sources\nvda\source\queueHandler.py", line 53, in flushQueue

func(*args,**kwargs)

File "C:\Documents and Settings\vtsaran\My Documents\sources\nvda\source\eventHandler.py", line 40, in _queueEventCallback

executeEvent(eventName,obj)

File "C:\Documents and Settings\vtsaran\My Documents\sources\nvda\source\eventHandler.py", line 73, in executeEvent

executeEvent_appModuleLevel(eventName,obj)

File "C:\Documents and Settings\vtsaran\My Documents\sources\nvda\source\eventHandler.py", line 111, in executeEvent_appModuleLevel

executeEvent_defaultAppModuleLevel(name,obj)

File "C:\Documents and Settings\vtsaran\My Documents\sources\nvda\source\eventHandler.py", line 118, in executeEvent_defaultAppModuleLevel

executeEvent_virtualBufferLevel(name,obj)

File "C:\Documents and Settings\vtsaran\My Documents\sources\nvda\source\eventHandler.py", line 125, in executeEvent_virtualBufferLevel

executeEvent_NVDAObjectLevel(name,obj)

File "C:\Documents and Settings\vtsaran\My Documents\sources\nvda\source\eventHandler.py", line 129, in executeEvent_NVDAObjectLevel

getattr(obj,'event_%s'%name)()

File "C:\Documents and Settings\vtsaran\My Documents\sources\nvda\source\NVDAObjects\IAccessible\MSHTML.py", line 174, in event_gainFocus

if self.isContentEditable:

File "C:\Documents and Settings\vtsaran\My Documents\sources\nvda\source\baseObject.py", line 23, in getattr

return getattr(self,'_get_%s'%name)()

File "C:\Documents and Settings\vtsaran\My Documents\sources\nvda\source\NVDAObjects\IAccessible\MSHTML.py", line 168, in _get_isContentEditable

if hasattr(self,'domElement') and self.domElement.isContentEditable:

File "C:\Python25\lib\site-packages\win32com\client\dynamic.py", line 496, in getattr

raise AttributeError?, "%s.%s" % (self._username_, attr)

AttributeError?: <unknown>.isContentEditable

[mdcurran]

Jamie and I are currently writing and testing a module for NVDA to take control of COM calls (to MSAA etc) that seem to block for ever. Using this module with NVDA and MS Outlook does stop a lot of the freezes, including this one. However, it does majorly stuff up the old virtualBuffers, so using this module with HTML messages isn't that good. However, once the in-process support for Internet Explorer_Server windows is written in with the new virtualBuffer library, then this will no longer be an issue.
So in short we are working on the issue, and things look promising. But this module really can't be used to fix these problems until MSHTML is supported in the new virtualBuffers.

[vtsaran]

While the new module is being worked on, is it possible to revert to the old behavior so that we can at least use Outlook 2003? At the moment none of the messages will read with NVDA.