GNOME Bugzilla – Bug 322964
LDAP stalls on contact search
Last modified: 2008-10-31 12:57:28 UTC
Please describe the problem: For various search criteria, the LDAP address book returns nothing in the GUI. The E-D-S logfile shows transactions occuring, but not completing when the GUI stalls. I have an example below. Steps to reproduce: 1. In Contacts, select LDAP address book 2. Search for name (scott) 3. Examine E-D-S logfile 4. Search for second name (sam) 5. Quit evolution, force shutdown Actual results: First search (scott) returns four records and displays correctly (I think). Second search (sam) returns nothing and stalls. Expected results: Second search (sam) should return one record. Does this happen every time? Yes. Other information: I'll attach the logfiles to the report. I have one logfile that shows the point where the stall occurs, and the seconds logfile shows the complete log after shutting evolution down.
Created attachment 55495 [details] Log file at stall point
Created attachment 55496 [details] Complete log file after shutdown
Notice in the complete logfile that the record for "sam" does show up at the end after the termination notice. It may be that the buffering causes the data to appear "out-of-order".
I have been playing around with this bug. One question I have is, when I send an ldap query, and the results stall (as seen by the logfile), is there any buffering going on before the results display to the screen? Am I really seeing all the data that has returned from the LDAP server? My hunch is that I am not, because when I run the same queries using ldapsearch from the command line, they return the full data with no stalls. My first guess is that something in the evolution query code gets hung up and prevents it from collecting the full query results.
can you unset GROUPWISE_DEBUG so that we will see only ldap traces on the console. For the search "scott" I see that results are obtained from the server. But for the search "sam" I don't see ldap search happening. Only the search for "sam" is failing or is it that, always first seach is successful and the second search fails?
Moving to NEEDINFO based on the last comment.
Sorry for the delay. I forgot you were waiting on more information. I did the search for "sam" first this time, and it stalled without displaying any records. Then I did the search for "scott", which did return results. I'll attach the E-D-S logfile without GROUPWISE_DEBUG set at the stall point after searching for "sam", and after searching for "scott"
Created attachment 60611 [details] Search for "sam" at the stalled point
Created attachment 60612 [details] Full log file after search for "scott" and shutdown
Debian unstable updated evolution-data-server, although the version is still the same (1.4.2.1). After a suggestion from a fellow user, I tried a different configuration where the 'use secure connection' option was set to 'Never'. I now get all records to return, the same as ldapsearch. However, now evolution-data-server is crashing after a few searches. I'm including some details about different configurations I have tried ('use secure connection' variations) and the search results. ------------- The summary is search scope "one" never works. Searches return nothing. Only search scope "sub" will return any contacts. Use secure "Never" returns the most matches. It returns the same contacts as ldapsearch. But it crashes. Use secure "Whenever Possible" and "Always" return the same matches. These crash too. Here are the details: Common Configuration Settings: Login method: Anonymously Search base: <empty> Timeout: 1 minute Download limit: 100 Variations: Configuration 1: ----------------- Port: 389 Use secure: Never/Always/Whenever Possible (tried each one) Search Scope: one Search experiments: 1. Name begins with "s" => Returns nothing 2. Name begins with "scott" => Returns 4 contacts 3. Name begins with "sam" => Returns nothing 4. Name begins with "scott" => Returns nothing (Does not crash) Configuration 2: ----------------- Port: 389 Use secure: Always Search Scope: sub Search experiments: 1. Name begins with "s" => Returns 20 contacts, including sam 2. Name begins with "scott" => Returns 4 contacts 3. Name begins with "sam" => Returns nothing 4. Name begins with "scott" => Returns 4 contacts (This is new: Just crashed the address book: The Evolution addressbook has quit unexpectedly. Your contacts for ldap://server.company.com:389/??sub will not be available until Evolution is restarted.) Configuration 3: ----------------- Port: 389 Use secure: Whenever Possible Search Scope: sub Search experiments: 1. Name begins with "s" => Returns 20 contacts, including sam 2. Name begins with "scott" => Returns 4 contacts 3. Name begins with "sam" => Returns nothing 4. Name begins with "scott" => Returns 4 contacts 5. Name begins with "m" => Returns 20 contacts 6. Clear (Crashed again: The Evolution addressbook has quit unexpectedly. Your contacts for ldap://server.company.com:389/??sub will not be available until Evolution is restarted.) Configuration 4: ----------------- Port: 389 Use secure: Never Search Scope: sub Search experiments: 1. Name begins with "s" => Returns 41 contacts, including sam 2. Name begins with "scott" => Returns 4 contacts 3. Name begins with "sam" => Returns 1 contact 4. Name begins with "m" => Returns 44 contacts 5. Name begins with "mo" => Returns 5 contacts (Crashed again: The Evolution addressbook has quit unexpectedly. Your contacts for ldap://server.company.com:389/??sub will not be available until Evolution is restarted.)
Created attachment 62941 [details] Bug buddy report of E-D-S crash This crash occurs in all 'search scope:' 'sub' modes, which is the only mode which returns any contacts.
crash doesn't look ldap handler specific. Did you upgrade your libraries?
I did update using a debian dist-upgrade using the unstable release. What libraries specifically should I check for incompatibilities?
can you please try in current stable 2.22.3, thanks in advance.
Thanks for taking the time to report this bug; however, closing due to lack of response of the reporter, sorry. if you still see this issue with a current release of evolution (2.24.x or later), please reopen. thanks in advance.