Bug 822445

Created attachment 585180 [details]
File: backtrace

Created attachment 585181 [details]
File: maps

Created attachment 585182 [details]
File: dso_list

Created attachment 585183 [details]
File: build_ids

Thanks for a bug report. I do not see from the backtrace why this could happen, it has probably something to do with your EWS account, but the backtrace is missing debug information for it. It crashed due to some memory corruption in one thread, though another thread does something in your EWS account and tries to print a critical warning on the console.

Maybe if you could run the addressbook factory from a console, under valgrind, then it'll show some issues which could happen during your work. The only thing is that any access to the addressbook will be significantly slower. You can run in under valgrind with command like this:
   $ G_SLICE=always-malloc,debug-blocks valgrind --num-callers=50 \
     /usr/libexec/evolution-addressbook-factory -w &>log.txt
and then on other console run evolution. Make sure there will be no other addressbook factory running before you execute the above command. Also make sure that you've installed debuginfo packages at least for evolution-data-server and evolution-ews, and that their version matches version of the binary packages.

I'll appreciate if it'll be done with 3.4.2 version, though you wrote into the update that it locks your account. It'll be good to investigate the reason for it, because it seems to me like a coincidence, because 3.4.2 doesn't contain any significant changes, at least I'm not aware of any in eds,evo,ews which could cause such account locking. Of course, the update requires restart of evolution processes (ps ax | grep evolution), to be sure that the correct binaries are running.

I'll try with 3.4.2 next week. I'm not strong enough to deal with internal IT for more account lockouts this week :-|

The lack of a decent backtrace is likely because I'm still using your evolution-ews-3.4.1-1.3.fc17 scratch build. Did those fixes for deletion/sync make it into 3.4.2?

(In reply to comment #6)
> I'll try with 3.4.2 next week. I'm not strong enough to deal with internal IT
> for more account lockouts this week :-|
> 
> The lack of a decent backtrace is likely because I'm still using your
> evolution-ews-3.4.1-1.3.fc17 scratch build. Did those fixes for deletion/sync
> make it into 3.4.2?

Yes, that's part of 3.4.2:
http://git.gnome.org/browse/evolution-ews/commit/?h=gnome-3-4&id=2f158e862760

(In reply to comment #6)
> I'll try with 3.4.2 next week. I'm not strong enough to deal with internal IT
> for more account lockouts this week :-|

I see. Do you still use evolution-mapi in parallel? I was told that GAL in evolution-mapi with exchange 2010 servers can lock the account. The problem is that this works fine with 2003 and 2007 servers and that I wasn't able to get any useful information from 2010 server admins about "why the account was locked". Knowing the reason will help in fixing it, though if you see this issue also with evolution-ews, without mapi being involved... Anyway, I'll appreciate if you could ask your IT department for the exact reason for the account being locked. They should know it, or be able to find out in some logs.

> I see. Do you still use evolution-mapi in parallel? I was told that GAL in
> evolution-mapi with exchange 2010 servers can lock the account. The problem is
> that this works fine with 2003 and 2007 servers and that I wasn't able to get
> any useful information from 2010 server admins about "why the account was
> locked". Knowing the reason will help in fixing it, though if you see this
> issue also with evolution-ews, without mapi being involved... Anyway, I'll
> appreciate if you could ask your IT department for the exact reason for the
> account being locked. They should know it, or be able to find out in some logs.

It's an exchange 2007 server, not sure if or what SP it has. I've cleaned everything out in terms of passwords, killed all existing evolution* processes, upgraded to 3.4.2 and started evolution with "evolution --offline" and then put it online and it hasn't locked out the account once I put it online and it prompted for password. It could well be the GAL stuff that caused the problem because I remember it prompting me for a GAL password and I've never really been able to access the GAL. If it runs OK for the day I'll push up the karma on the update

Upgrading to 3.4.2 I get two password prompts every time i try to reply to or compose an email. One for my personal contacts on exchange and one for the GAL. 

It also seems that on occasion the evolution-addressbook-factory freezes causing the message window to display the "Formatting Message…" with a white window. If I quit Evolution you can see the message display momentary before it quits.

And i'm back to lockouts. It definitely appears to be related to when ever I'm composing email and it's checking GAL

confirmed it's exchange 2007

(In reply to comment #11)
> And i'm back to lockouts. It definitely appears to be related to when ever I'm
> composing email and it's checking GAL

Are you accessing GAL with evolution-mapi? I understood that you use evolution-ews, and its GAL implementation is way different from that in evolution-mapi. I would say, if you've GAL with evolution-mapi, and you do not use evolution-mapi for anything else, then just disable that account, or uncheck GAL from Edit->Preferences->Contacts for autocompletion.

(In reply to comment #12)
> confirmed it's exchange 2007

Hmm, I never got account lockout on my server (at least yet), though it can be some server policy about often connect/disconnect, server rejecting NSPI connections only (the evo-mapi uses NSPI for GAL directly, there is basically no other Inbox checking or any other folder opening, only the store and NSPI connection is opened) or something (un)like that.

I forgot to mention, this change is in evo-mapi since 3.4.0. Looking on changes in evo-mapi between 3.4.1 and 3.4.2 there are only two possible, one about kerberos login (to not try kerberos when not enabled by a user), and one for GAL named IDs fetching. It seems the later does the trouble here, though the change seems to be pretty harmless, it only fetches named properties from Contacts folder, if they are not found on GAL folder itself (previous version, 3.4.1, only checked in GAL, but later I realized that usually returns nothing, thus I added this fallback).

(In reply to comment #13)
> (In reply to comment #11)
> > And i'm back to lockouts. It definitely appears to be related to when ever I'm
> > composing email and it's checking GAL
> 
> Are you accessing GAL with evolution-mapi? I understood that you use
> evolution-ews, and its GAL implementation is way different from that in
> evolution-mapi. I would say, if you've GAL with evolution-mapi, and you do not
> use evolution-mapi for anything else, then just disable that account, or
> uncheck GAL from Edit->Preferences->Contacts for autocompletion.

No, this is using my EWS configuration. mapi doesn't work outside our corporate network as it doesn't support HTTP Proxy so it's long been disabled so as to not cause issues. Although looking at the Contacts page it looks like it might be trying to use them based on the naming of the accounts, should it even attempt to use details from a disabled account? It's hard to tell which account it is as it has the email and not the name I've given the account and the email address is obviously the same for the mapi/ews account.

> (In reply to comment #12)
> > confirmed it's exchange 2007
> 
> Hmm, I never got account lockout on my server (at least yet), though it can be
> some server policy about often connect/disconnect, server rejecting NSPI
> connections only (the evo-mapi uses NSPI for GAL directly, there is basically
> no other Inbox checking or any other folder opening, only the store and NSPI
> connection is opened) or something (un)like that.

We have a corporate lock out policy. It's never really caused me an issue before.

(In reply to comment #15)
> No, this is using my EWS configuration. mapi doesn't work outside our
> corporate network as it doesn't support HTTP Proxy so it's long been
> disabled so as to not cause issues. Although looking at the Contacts page it
> looks like it might be trying to use them based on the naming of the
> accounts, should it even attempt to use details from a disabled account?
> It's hard to tell which account it is as it has the email and not the name
> I've given the account and the email address is obviously the same for the
> mapi/ews account.

You might notice from the GAL properties, though there is probably not named the account type. It sometimes could/can happen that account disable didn't remove all the around sources, like in Contacts or Calendar. Try this command:
   $ gconftool-2 --get /apps/evolution/addressbook/sources | grep mapi
it should return nothing, if there is no mapi addres book. It can use information from disabled mail account, because it's a separate source, with the only connection being done by evolution-mapi plugin, otherwise the are basically independent. If you'll find it there, then I usggest to open gconf-editor, open the above named key a remove the mapi GAL book on your own.

> We have a corporate lock out policy. It's never really caused me an issue
> before.

Do you know how that is setup, please (what is the rule, and possible where to find it on the server)? I would try to repeat it here and test what I can do with it.

>    $ gconftool-2 --get /apps/evolution/addressbook/sources | grep mapi

Returns nothing

> > We have a corporate lock out policy. It's never really caused me an issue
> > before.
> 
> Do you know how that is setup, please (what is the rule, and possible where
> to find it on the server)? I would try to repeat it here and test what I can
> do with it.

It's within Active Directory.

Detailed overview: http://technet.microsoft.com/en-us/library/cc770394%28v=WS.10%29.aspx

Quick GUI ways of enabling it 
http://technet.microsoft.com/en-us/library/dd277400.aspx
http://technet.microsoft.com/en-us/library/cc781491%28v=ws.10%29.aspx

Oh, I'm sorry, I missed your reply, I would comment earlier otherwise.

(In reply to comment #17)
> >    $ gconftool-2 --get /apps/evolution/addressbook/sources | grep mapi
> 
> Returns nothing

Good, that means this is not on MAPI.

> > > We have a corporate lock out policy. It's never really caused me an issue
> > > before.
> > 
> > Do you know how that is setup, please (what is the rule, and possible where
> > to find it on the server)? I would try to repeat it here and test what I can
> > do with it.
> 
> It's within Active Directory.

I see. So you have set locking on failed login attempts. It seems like evolution has stored invalid password for one component, probably addressbook, and it doesn't ask for "correct" version of it, instead repeatedly tries with wrong password until it results in account lock. If you are not using evolution-mapi, then it can be only evolution-ews, I'll test it here and let you know. (Did we move too far from the initial issue here?)

Maybe the account lock is cased by the same issue as bug #821307.

(In reply to comment #19)
> Maybe the account lock is cased by the same issue as bug #821307.

Could be, reading that and bug #821228 it sounds like some of the issues I've seen where the calendar will prompt for the password (evo isn't running) even though it has the password in the keyring.

I've also seen cases where the email won't render (just displays "formating message") and I have to kill evo with al "evolution --force-shutdown" and then I have to kill evolution-addressbook-factory and then restart evo to get it to render mail. I'm not sure if that's related either.

(In reply to comment #20)
> I've also seen cases where the email won't render (just displays "formating
> message") and I have to kill evo with al "evolution --force-shutdown" and
> then I have to kill evolution-addressbook-factory and then restart evo to
> get it to render mail. I'm not sure if that's related either.

That might be bug #818864

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.