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 [139.131.1.14]) 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 soon. 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/
- edbinfo from hell Luis P. Caamano
- Re: edbinfo from hell Contractor Robert J. Eustace Mr
- Re: edbinfo from hell Luis P. Caamano