edbinfo from hell

"Luis P. Caamano" <lpc@sware.com> Fri, 04 August 1995 16:25 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12176; 4 Aug 95 12:25 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12171; 4 Aug 95 12:25 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa13045; 4 Aug 95 12:24 EDT
Received: from bastion.sware.com by haig.cs.ucl.ac.uk with Internet SMTP id <g.03626-0@haig.cs.ucl.ac.uk>; Fri, 4 Aug 1995 15:51:54 +0100
Received: from shlep.sware.com (shlep.sware.com []) by bastion.sware.com (8.6.12/8.6.5) with SMTP id KAA03366; Fri, 4 Aug 1995 10:46:14 -0400
Received: by shlep.sware.com (5.65/2.0) from alehouse.sware.com id AA09034; Fri, 4 Aug 95 10:46:29 -0400
Received: by alehouse.sware.com (5.65/2.1) from localhost id AA00986; Fri, 4 Aug 95 10:47:16 -0400
X-Orig-Sender: "Luis P. Caamano" <lpc@sware.com>
Message-Id: <9508041447.AA00986@alehouse.sware.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Luis P. Caamano" <lpc@sware.com>
X-Mailer: SecureMail [2.1.2]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: quipu <quipu@cs.ucl.ac.uk>
Subject: edbinfo from hell
Cc: LDAP mailing list <ldap@umich.edu>, OSI-DS <osi-ds@cs.ucl.ac.uk>
Date: Fri, 04 Aug 1995 10:47:16 -0400

Our DSA got killed by an edb update that included the 7/30/95 update of
c=US, cn=Long Bud, which now has an edbinfo with about 939 values.  The
edbinfo itself seems to be legal but if everybody starts having
edbinfos like that, we better start dropping quipu's memory database

The reason ours got killed is that we're running quipu 8.0 which seems
to have really bad memory leaks.  Our dsa, while processing that edb
update, hit the sbrk maximum and couldn't get any more memory.  It
tried to restart, but the new EDB causes it to grow beyond the 20MB
limit at startup time!!  The dsa spent about 30 hours restarting until
we noticed, that is, it would start, try to read c=US/EDB, which now
has the huge edbinfo from Long Bud, and then sbrk would fail and next
it would try to restart, and repeat the loop.

At this point, we have several options: a) increase the max sbrk value
per user in the kernel (the quick, dirty, fix), b) fix the edb related
memory leaks.  If there are any other options, pls tell me so.

The reason I'm posting this is b).  I've noticed that the quipu's
memory leak appear to be really bad at edb processing time.  Before
going into the debugger and studying all the edb code, I thought it to
be wise to ask around here for any bug fixes.  Am I lucky?  :)

I have to confess that I don't have much hope of getting anything,
judging from experience in these X.500 mailing lists, but who knows,
perhaps some merciful soul out there might send me some pointers as to
what or where to look.

X500'ly yours

Luis P. Caamano  (LC2385)             |           lpc@sware.com
SecureWare, Inc. Atlanta, GA, USA     |           (404) 315-6296
E-mail privacy by SecureMail, see http://www.secureware.com/