After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 322964 - LDAP stalls on contact search
LDAP stalls on contact search
Status: RESOLVED OBSOLETE
Product: evolution-data-server
Classification: Platform
Component: Contacts
1.4.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2005-12-01 20:47 UTC by Scott Anderson
Modified: 2008-10-31 12:57 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Log file at stall point (54.96 KB, text/plain)
2005-12-01 20:47 UTC, Scott Anderson
Details
Complete log file after shutdown (59.52 KB, text/plain)
2005-12-01 20:47 UTC, Scott Anderson
Details
Search for "sam" at the stalled point (7.74 KB, text/plain)
2006-03-03 23:55 UTC, Scott Anderson
Details
Full log file after search for "scott" and shutdown (16.73 KB, text/plain)
2006-03-03 23:56 UTC, Scott Anderson
Details
Bug buddy report of E-D-S crash (10.22 KB, text/plain)
2006-04-07 17:44 UTC, Scott Anderson
Details

Description Scott Anderson 2005-12-01 20:47:01 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.
Comment 1 Scott Anderson 2005-12-01 20:47:35 UTC
Created attachment 55495 [details]
Log file at stall point
Comment 2 Scott Anderson 2005-12-01 20:47:57 UTC
Created attachment 55496 [details]
Complete log file after shutdown
Comment 3 Scott Anderson 2005-12-01 20:50:39 UTC
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".
Comment 4 Scott Anderson 2006-01-06 18:40:33 UTC
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.
Comment 5 Sushma Rai 2006-01-09 05:43:56 UTC
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?
Comment 6 Devashish Sharma 2006-02-26 10:10:36 UTC
Moving to NEEDINFO based on the last comment.
Comment 7 Scott Anderson 2006-03-03 23:50:00 UTC
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"
Comment 8 Scott Anderson 2006-03-03 23:55:19 UTC
Created attachment 60611 [details]
Search for "sam" at the stalled point
Comment 9 Scott Anderson 2006-03-03 23:56:02 UTC
Created attachment 60612 [details]
Full log file after search for "scott" and shutdown
Comment 10 Scott Anderson 2006-04-07 17:42:35 UTC
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.)

Comment 11 Scott Anderson 2006-04-07 17:44:53 UTC
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.
Comment 12 Sushma Rai 2006-04-10 04:10:35 UTC
crash doesn't look ldap handler specific. Did you upgrade your libraries?
Comment 13 Scott Anderson 2006-04-11 22:29:00 UTC
I did update using a debian dist-upgrade using the unstable release.  What libraries specifically should I check for incompatibilities?
Comment 14 Akhil Laddha 2008-08-11 06:46:49 UTC
can you please try in current stable 2.22.3, thanks in advance.
Comment 15 Akhil Laddha 2008-10-31 12:57:28 UTC
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.