Path: utzoo!utgpu!watserv1!watmath!att!att!emory!sol.ctr.columbia.edu!samsung!usc!sdd.hp.com!ucsd!ucbvax!BNR.CA!PWW
From: PWW@BNR.CA (Peter  Whittaker, P.W.)
Newsgroups: comp.protocols.iso.dev-environ
Subject: Memory leaks in ISODE stack.
Message-ID: <90Oct29.110651est.57692@ugw.utcs.utoronto.ca>
Date: 29 Oct 90 14:57:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 57

Hello, we're running ISODE 6.1+ patches on SUNs (4.0.3) and HP-UX 6.5,
and we seem to be having memory leakage problems.

We are already aware of certain memory leaks in the QUIPU-specific code
(entry.c, oper_act.c, update.c)  but these problems seem to be more
at the Transport Layer of ISODE.

The leaks were discovered by a test case that attempts several thousand
bind/unbind operations.  On a SUN with 65 Meg, it takes between 10- and
20 000 of these operations for the DSA to fail, while a DUA on an H/P with
8 - 16 M fails after about 6000 operations.

Furthermore, when the DUA starts its binding, it manages 3 or 4 bind/unbind
pairs a second.  After about an hour, it's down to 1 every 3 0r 4 seconds
(i.e. the DUA grows and grows, becoming more and more of a load on machine
resources, esp. pager and swapper).

The transport layer is suspected for two reasons:

i) there's a synching problem with the ISODE stack as well:
   if three DUAs on three separate machines all attempt the bind/unbind
   tests simultaneoulsy, one will invariably "win out", and complete
   its bind/unbinds in 'normal' time.  The other two will 'lock' their
   TCP connections, and not 'hang' until they, or the DSA, are killed.
   (This 'winning out' usually manifests itself after about 60 minutes
    - roughly 500 binds per DUA).

   (All data in the TCP exchange is good (no bad packets, dropped packets,
   or collisions):  this thanks to a LanAnalyzer.)

   The DSA writes in its stats.log that it received a ds_unbind-request,
   and that the connection was dropped, but the connection persists.

   So, we suspect that somewhere in the application stack a routine
   'forgets' to either set or clear some data object.

ii) Because the bind/unbind operations do not involve any other DUA/DSA
    operations, there is a minimal amount of ASN.1/BER manipulation going
    on, so the presentation and session layers aren't suspected: ergo,
    transport layer.

(a third circumstantial reason is that the first error reported when the
DUAs fail is A-ASSOCIATE.REQUEST out of memory, accompanied by

TAsynConnRequest: Congestion at TSAP :out of memory:
SAsynConnRequest(pseudo): Congestion at SSAP
ppktlose :Temporary congestion:
PAsynConnRequest(pseudo): Temporary congestion

The 'circumstantial evidence' is that the transport function is the
first that reports an error.)

Has anyone else had similar problems with ISODE?

Thanks,

Peter W.