AsnBuf has changed a lot over the
years. eSNACC may still have the same functionality of InstallData(), but
that member function not longer exists. If I recall correctly, if
you used InstallData() you are responsible for memory cleanup not eSNACC.
But that’s just the memory associated with the buffer.
You are destroying the object you decoded
into correct?
With your memory tool you should be able
to track down which component of your spec. is leaking memory. For
example, is it an ANY, OCTET STRING, …
-Pierce
From:
owner-imc-snacc@xxxxxxxxxxxx [mailto:owner-imc-snacc@xxxxxxxxxxxx] On Behalf Of Kearn, Simon (EXP)
Sent: Friday, March 03, 2006 5:36
AM
To: imc-snacc@xxxxxxx
Subject: Problems with Memory
allocation in ASN.1
I am currently working with ASN.1 to ensure that the data
structures
used
by myself and our suppliers conform to a generic standard when
passing
messages over the network. The application I have written has
been
established now for a number of years and is written in C++. The
ASN.1
compiler being used is the snacc compiler version 1.3.
I have a problem though in that when I decode a message from a
network
representation
into ASN.1, I first create an AsnBuf and then call the
function
InstallData. Then set the mode to be read only. This all works
fine
but then when I call the Decode routine (in the case of the snacc
compiler
it is BDecPdu) the memory gets allocated by the system and the
underlying
message is extracted. However that memory does not seem to be
released,
until the end of the application.
The problem is that I have a machine with 1.5 GB of memory where
about
1.17Gb
is used during my application run. The application passes
messages
of about 800 bytes through at 10-12 a second. The memory starts
off
at 139MB and grows at about 1MB a second. When I use a leak detector
application
it tells me that the decode routine of the ASN.1 is causing
a
lot of memory leaks, and yet I have seen through using debug that a call
is
made to the destructor for each of the ASN.1 message types created, thus
calling
delete to get rid of each of the underlying types created.
Can you by any chance help me in trying to identify why the
memory is
being
used up so much.
Many thanks for your time and effort.
Simon Kearn
Software Engineer
*simon.kearn@xxxxxxxx