GNOME Bugzilla – Bug 306872
ldap automatic completion freezes the evolution mailer
Last modified: 2005-08-19 07:13:15 UTC
Steps to reproduce: I m using evolution 2.3.2 from the ubuntu breedy distribution on x86 linux 2.6.12-rc6 with kde 3.4 environnement Now nearly each time I use the automatic completion with ldap search when I want to add a recipient to a mail the mailer is totally stucked. I have this problem for ages but now it happens nearly everytime Stack trace: (gdb) thread apply all bt
+ Trace 60701
Other information: When it s stuck I need to execute the killev command and I also need to kill the evolution data server
Here is a backtrace of the evolution-data-server-1.4 process :
+ Trace 60776
Thread 3 (Thread -1258202192 (LWP 31690))
Thread 2 (Thread -1230619728 (LWP 31705))
Thread 1 (Thread -1219586368 (LWP 31521))
Malf: Is your scenario is something like in bug 309776 ?
Nagappan : No there is perhaps a memory issue too , but the fact is that I cant add any new recipient because evolution is completely stucked. When I kill e-d-s the current instance of evolution reworks ( minus e-d-s ). Is it clearer ?
No it's not the problem in bug 309776. malf: How many address books are marked for autocompletion? Also are you using SSL with LDAP server?
Sushma Rai: I have 2 address books : one local one ldap I m not using ssl
malf: Can you uncken the option "Copy book content locally for offline operation", in the properties dialog for the LDAP book and restrd e-d-s and check this? Just want to confirm that if local cache update is causing this. How may objects your LDAP server is having?
I have unchecked the option . I have just made a test with the latest release ( 2.3.7 ) of evolution from the ubuntu unstable distribution. The e-d-s release number is 1.3.7-0Ubuntu1 Now each time I type a recipient in a mail, a message appears and says "e-d-s has crashed unexpectedly". ldap part which is accessible anonymously by evolution contains 150 records. By the way all those new releases of evolution are really unstable , but yes I know it s another problem and it s my fault to use such an unstable distribution for work :(
I am using ldap backend with my test server with 10K objects, and it is working fine. sometimes I see a high CPU usage while building the cache, but it comes down once the cache is populated. Can you attach the stack traces for crash?
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1238926416 (LWP 4926)] 0x00000000 in ?? () (gdb) thread apply all bt
+ Trace 62495
Thread 1 (Thread -1218505024 (LWP 4881))
*** This bug has been marked as a duplicate of 300157 ***