Bug 204808

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