Bug 204808 - spurious search timeouts
spurious search timeouts
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Database - Indexes/Searches (Show other bugs)
1.0.2
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
:
Depends On:
Blocks: 152373 fds103trackingbug 240316
  Show dependency treegraph
 
Reported: 2006-08-31 13:48 EDT by Robert Viduya
Modified: 2015-12-07 11:34 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 11:34:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
text and code snippits detailing the problem cause (2.66 KB, text/plain)
2006-08-31 13:48 EDT, Robert Viduya
no flags Details
cvs diffs cb_search.c, pblock.c, search.c (3.06 KB, patch)
2006-10-04 20:20 EDT, Noriko Hosoi
no flags Details | Diff
cvs commit message (939 bytes, text/plain)
2006-10-05 17:15 EDT, Noriko Hosoi
no flags Details

  None (edit)
Description Robert Viduya 2006-08-31 13:48:27 EDT
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
Comment 1 Robert Viduya 2006-08-31 13:48:27 EDT
Created attachment 135312 [details]
text and code snippits detailing the problem cause
Comment 2 Noriko Hosoi 2006-09-19 18:31:45 EDT
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);
Comment 3 Noriko Hosoi 2006-10-04 20:20:15 EDT
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"
Comment 4 Rich Megginson 2006-10-04 22:27:31 EDT
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.
Comment 5 Noriko Hosoi 2006-10-05 17:15:19 EDT
Created attachment 137866 [details]
cvs commit message

Thanks for reviewing the changes, Rich.
Checked in into HEAD.
Comment 6 Rich Megginson 2006-10-05 17:20:59 EDT
Marking this as a FDS 1.0.3 candidate fix
Comment 7 Noriko Hosoi 2006-10-13 21:32:30 EDT
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...
Comment 8 Rich Megginson 2006-10-13 23:11:49 EDT
Ok.  Looks good.  There is still time to get this into fds103.
Comment 9 Noriko Hosoi 2006-10-14 02:20:00 EDT
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

Note You need to log in before you can comment on or make changes to this bug.