PWW@BNR.CA (Peter Whittaker, P.W.) (10/29/90)
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.mrose@CHEETAH.CA.PSI.COM (Marshall Rose) (10/30/90)
There were a few memory leaks in 6.0+. These are believed to be fixed in the current beta, 6.6 /mtr
sean@DSL.PITT.EDU (Sean McLinden) (10/31/90)
I, too, have experienced memory leaks on DEC3100 (MIPS) running Ultrix 3.1, 3.2, and 4.0. At first I thought that it was due to problems with the MIPS C compiler, and was going to try compiling with GNU, but with warnings enabled I got nearly 200 pages of possible problems and gave up trying to find out where they all were. Most of our problems stem from running QUIPU. It would run about 18 hours and then die. Restarting got to be a problem because the startup DSA gets overwritten once the data is fetched from the master, but what is fetched cannot be used to restart the DSA. If there are patches to the QUIPU code, that might help. I had alwasy assumed that the problem was there because we could run the rest of the ISODE for days without problems (but then, nothing banged on it as much as QUIPU). Sean McLinden Decision Systems Laboratory University of Pittsburgh
c.robbins@xtel.co.uk (Colin Robbins) (05/17/91)
Most, if not all of these problems have been fixed in ISODE/QUIPU 6.8. Colin
PWW@BNR.CA (Peter Whittaker, P.W.) (06/11/91)
> Most, if not all of these problems have been fixed in ISODE/QUIPU 6.8. > > Colin > Hmm, curious. The post to which Colin is replying is one that I originally posted last year (i.e. late in 1990). I was very surprised to see it reappear (especially May 17th - I left the office on the 16th, and only returned today - June 11th). Has anyone's mailer software or list maintenance software been burping up old articles? Curioser and curioser,