OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Archive.Software Bugs/338
Full headers

From: paul@auroragrp.com
Subject: write block in ber_flush under Solaris 2.6
Compose comment
Download message
State:
0 replies:
2 followups: 1 2

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 29 Oct 1999 03:09:13 GMT
From: paul@auroragrp.com
To: openldap-its@OpenLDAP.org
Subject: write block in ber_flush under Solaris 2.6
Full_Name: Paul Amaranth
Version: 1.2.3 & 1.2.7
OS: Solaris 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (208.231.254.31)


We have a product that uses OpenLDAP libraries to communicate with a remote LDAP
server.
When the client machine load spikes to 100%, the client program becomes
blocked.
After 30 minutes or so, it will unblock and regain normal behavior, but this is
unacceptable for a server (the client is an authentication server).  This is
being built and executed on a Solaris 2.6 system.

Attaching to the blocked process with gdb, I see the following:

#0  0xef5391a4 in _write () from /usr/lib/libc.so.1
#1  0xef46645c in ber_flush (sb=0xbb7b0, ber=0x20a210, freeit=0) at io.c:318
#2  0xef462b08 in ldap_send_server_request (ld=0xbb7b0, ber=0x20a210, 
    msgid=5266, parentreq=0x0, srvlist=0x0, lc=0xc0e68, bind=0)
    at request.c:255
#3  0xef4628f8 in ldap_send_initial_request (ld=0xbb7b0, msgtype=99, 
    dn=0xc0e44 "o=Company Name,c=US", ber=0x20a210) at request.c:169
#4  0xef45f61c in ldap_search (ld=0xbb7b0, 
    base=0xc0e44 "o=Company Name,c=US", scope=2, 
    filter=0x1fce08 "uid=t020l", attrs=0x0, attrsonly=0) at search.c:79

This has happened with OpenLDAP 1.2.3 and 1.2.7.  This has happened with
versions configured without threads and using Solaris lwp.  This has
happened with versions compiled with gcc 2.8.1 and the egcs-1.1.2 release.

If the library was compiled with gcc 2.8.1, it would block at a significantly
lower CPU load, maybe 70% utilization.  The later egcs release is more
robust, but it will block if the CPU utilization maxes out. The point at
which the CPU maxes out is about 15-20 LDAP queries/second, more or less.
It always blocks at the same place.

Anyone have _any_ ideas?  We're a little frustrated by this and we have
a rollout deadline coming up.  Any help will be greatly appreciated.

Followup 1

Download message
From: paul@AuroraGrp.Com
Subject: Re: write block in ber_flush under Solaris 2.6  (ITS#338)
To: openldap-its@OpenLDAP.org
Date: Thu, 23 Dec 1999 14:32:35 -0500 (EST)
This error is apparently caused when there is more than one outstanding
asynchronous request (bind or search) without calling ldap_result().

The documention should note that ldap_result() should be called immediately
after every asynchronous call. 

> 
> 
> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
> 
> Thanks for your report to openldap-its@OpenLDAP.org.  Your report
> has been placed into our Issue Tracking System and has been assigned
> the tracking number ITS#338.
> 
> One of support engineers will look at your report in due course.
> Note that this may take some time because our support engineers
> are volunteers.  They only work on OpenLDAP when they have spare
> time.
> 
> You may follow the progress of this message by loading the following
> URL in a web browser:
> 
>     http://www.OpenLDAP.org/its/index.cgi?findid=338
> 
> Please remember to retain your issue tracking number (ITS#338)
> on any further messages you send to us regarding this message.  If
> you don't then you'll just waste our time and yours because we
> won't be able to properly track the message.
> 
> In our experience many people ask questions that have been asked
> before.  We recommend that you review our online FAQ
> 
> 	http://www.OpenLDAP.org/faq/
> 
> and search archives of our many mailing lists (such as openldap-software
> and openldap-bugs). 
> 
> 	http://www.OpenLDAP.org/lists/#archives
> 
> --------------
> Copyright 1999 The OpenLDAP Foundation, All Rights Reserved.
> 


-- 
Paul Amaranth        | Rochester MI, USA    
Aurora Group, Inc.   |   Systems & Software 
paul@AuroraGrp.Com   |   Unix / Windows / NT



Followup 2

Download message
Date: Thu, 23 Dec 1999 12:56:35 -0800
To: paul@AuroraGrp.Com
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.Org>
Subject: Re: write block in ber_flush under Solaris 2.6  (ITS#338)
Cc: openldap-its@OpenLDAP.Org
Note that the Async API is with respect to the protocol, not to
I/O.

At 07:29 PM 12/23/99 GMT, paul@AuroraGrp.Com wrote:
>This error is apparently caused when there is more than one outstanding
>asynchronous request (bind or search) without calling ldap_result().

The whole purpose of having an async API is to support multiple
outstanding requests.  ldap_result supports a variety of mechanism
for polling (or waiting) for responses.

	Kurt



Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org