Page MenuHome GnuPG

GpgOL - Outlook running out of resorces
Closed, ResolvedPublic

Description

Since installing gpg4win 3.0.0 I've had a number of occasions where outlook (Office 365) appears to stop working. Copy/Paste doesn't work, send doesn't work, opening emails doesn't work and some other stuff and, when I change folders in Outlook, it will show up the message:

"cannot display the folder. out of memory or system resources."

When I uninstalled gpg4win/GpgOL this problem went away.

Details

Version
3.0.0

Event Timeline

File uploaded is the gpgol debug log file, 7-zipped (it's 165MB without zipping).

@cosimo193 ; gpg4win 3.0.1 just was released. May you check if this error still exists with that new version?

When you say "just was released", do you know what time that was at? My reason for asking is that I checked for an update just before posting this bug report! I'll try it and see how it goes.

Thanks

by "just released" I mean: minutes before i wrote that comment. Since you mentioned gpg4win 3.0.0 in your post, I think you worked with the now old stable release.

Thanks for that clarification Jochen; at least it confirms I'm not going mad. I've got it installed now so will update this if it happens again although, in the meantime, it might be taking a look at the log I attached (if you haven't already) to see if it hints at any behaviour that you know has been fixed.

Many thanks
John

aheinecke triaged this task as High priority.
aheinecke added a subscriber: aheinecke.

What happens in the log:

  • We see an ItemLoad event which "should" only happen when a new mail is selected / viewed
  • Check if the Mail is encrypted / signed (it is not)
  • GpgOL invalidates the UI to ensure that no wrong Signature / Crypto state is shown in the ribbon
  • We see an unload event the internal resources for this mail should be freed.
  • We see an ItemLoad event... and repeat

This loops so often that it can't be because many mails are selected / viewed. And this will likely block any other stuff outlook is doing because it's stuck in that loop.
Now we probably leak some memory in the load / unload loop or outlook does. The loop is the problem here and probably caused by the invalidation. I've seen this before but I fixed it and can't reproduce it now.

I'll take a look. The 3.0.1 Update won't help here.

From the log it looks to me a bit like you don't have a reading / preview pane enabled? Is this correct?
If you find out what triggers the loop for you please let us know.

Thanks for that assessment.

From the log it looks to me a bit like you don't have a reading / preview pane enabled? Is this correct?

That is correct. I try to avoid using the reading pane in all folders.

If you find out what triggers the loop for you please let us know.

I'll bear your comments in mind and try to remember what I've been doing if I see that again.

I think I fixed your problem. We had a similar problem in the past and the fix there was not to invalidate the UI (Update GpgOL's status button) so quickly when the selection changed.

Now we queue invalidations and delay them by 500ms ensuring that at max only every 500ms an invalidation happens. This should give Outlook enough time to properly handle everything and avoid the loop.

Can you please replace your gpgol.dll with the latest version from: http://files.gpg4win.org/Beta/gpgol/ ( 2.0.4-beta3 ) and confirm that the problem is gone?

It might also be gone with gpg4win-3.0.1 because that acutally has a bug (which I noticed while looking at this problem) that it updates the UI not often enough....

Thanks for your help!
Andre

Thanks. I'll give that a go. The only issue here is that it takes quite a long, random time to happen so chances are a successful fix is one where I never revisit this ticket :-)

BTW - having looked at the log that's been created with the 3.0.1 version, it looks like there was still a loop issue in there. E.g., I've extracted these lines from the log and copied the message ID to the start of the line (just so that I could sort). Without sorting they're interspersed with lines for other message IDs, but there's definitely the appearance of a possibly inappropriate loop in there.:

287666B0 16:18:25/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:25/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:25/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:26/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287666B0 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.

(here's a small segment of unsorted lines...)
287666B0 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287658F0 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287658F0.
28765D10 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 28765D10.
28765898 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 28765898.
28765E70 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 28765E70.
28764A28 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 28764A28.
287666B0 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.
287658F0 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287658F0.
28765D10 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 28765D10.
28765898 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 28765898.
28765E70 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 28765E70.
28764A28 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 28764A28.
287666B0 16:18:27/6532/mailitem-events.cpp:Invoke: Removing Mail for message: 287666B0.

I can reproduce a similar behavior when selecting all mails in a large folder. This was for T3433 It's not a loop it's just a huge load of "Read" events Outlook sends GpgOL and GpgOL looks at every mail.

I also then get blocks of "Removing Mail for message: ...." debug messages.

aheinecke changed the task status from Open to Testing.Nov 24 2017, 2:56 PM

I fixed the problem with multiselection that caused a very similar log for me. The fix is now in 2.0.4-beta6

Does this still happen with gpg4win-3.0.2?

I only installed 3.0.2 this morning so this hasn't had much of a chance to happen.

No more reports of this since 3.0.2. With 3.0.3 I fixed an additional memleak which should further improve this. Resolved for now.