Description of problem: Running the 64-bit version of the directory on 64-bit linux, we are seeing random timeouts from our search with a reported elapsed time of zero. Version-Release number of selected component (if applicable): How reproducible: Random, sometimes we can go hours without seeing any problems, sometimes we get a whole bunch of them in a row. Steps to Reproduce: Just execute searches until it happens. Actual results: see attached Expected results: see attached Additional info: see attached
Created attachment 135312 [details] text and code snippits detailing the problem cause
You are right. time_t and int are mixed up. Time related functions (e.g., current_time() in time.c) treats time with time_t, but some codes declare int for the time and pblock handles the type with int. Sample "int" is being used. slapi-private.h: typedef struct slapi_operation_parameters { [...] struct search_parameters { [...] int search_timelimit; [...] } p_search; } void be_set_timelimit(Slapi_Backend * be, int timelimit);
Created attachment 137787 [details] cvs diffs cb_search.c, pblock.c, search.c (In reply to comment #1) > Created an attachment (id=135312) [edit] > text and code snippits detailing the problem cause Thank you for debugging the bug. The attachment is a proposed fix based upon your suggestion. Files: ldap/servers/plugins/chainingdb/cb_search.c ldap/servers/slapd/pblock.c ldap/servers/slapd/back-ldif/search.c Changes: 1) cb_search.c: chainingdb_next_search_entry declared int for optime. replaced it with time_t. 2) pblock.c: See attachment "135312: text and code snippits detailing the problem cause"
Yep, looks good. time_t is definitely 8 bytes on 64bit machines, so we need to be consistent and use time_t everywhere for OPINITIATED_TIME.
Created attachment 137866 [details] cvs commit message Thanks for reviewing the changes, Rich. Checked in into HEAD.
Marking this as a FDS 1.0.3 candidate fix
There was one more type mismatch in the backend. The error is observed when sort is on: $ ./ldapsearch -1 -b o=vlv.com -D <user> -w <passwd> -p <port> -G 1:1:aaa -x -S uid uid=* uid ldap_search: Timelimit exceeded ldap_parse_sort_control: Requested LDAP control not found ERROR executing last command. Due to the mismatch, even though the timelimit was not specified, it was accidentally treated as "timelimit == 0" on some platform (in this case HP-UX) and the search was failing. With this fix, timelimit == -1 (no time limit, internally) is correctly retrieved and time limit error does not occur. Index: ldbm_search.c =================================================================== RCS file: /cvs/dirsec/ldapserver/ldap/servers/slapd/back-ldbm/ldbm_search.c,v retrieving revision 1.7 diff -t -w -U4 -r1.7 ldbm_search.c --- ldbm_search.c 24 May 2006 20:49:15 -0000 1.7 +++ ldbm_search.c 14 Oct 2006 01:21:01 -0000 @@ -421,9 +421,9 @@ */ if (sort && (NULL != candidates)) { time_t optime = 0; - time_t tlimit = 0; + int tlimit = 0; slapi_pblock_get( pb, SLAPI_SEARCH_TIMELIMIT, &tlimit ); slapi_pblock_get( pb, SLAPI_OPINITIATED_TIME, &optime ); /* Rich, this fix would be better be in FDS 1.0.3, as well...
Ok. Looks good. There is still time to get this into fds103.
Thank you, Rich! Checked in into HEAD. [CVS commit message] Resolves: #204808 spurious search timeouts (comment #7) fixed anoter int vs. time_t type mismatch. CVS: ---------------------------------------------------------------------- CVS: Modified Files: CVS: ldbm_search.c CVS: ---------------------------------------------------------------------- Checking in ldbm_search.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/back-ldbm/ldbm_search.c,v <-- ldbm_search.c new revision: 1.8; previous revision: 1.7 done