RE: XalanC XalanDOMString and memory release!

[Olivier Moises <co...@generic-concept.com>]

Hi Dave,

First I want to tell you thank you another time for your help about my
compile options on Windows (multithreaded DLL).

The both distributions of my program work now without any increasing memory
usage.
I tested 10 millions loops of (small) transformations with success.

But  I found something abnormal (I think):


XSLTInputSource myInputXMLSource ("my system id");
MyXMLInputSource.setStream (aStream);

...

theXalanTransformer.transform (myInputXMLSource, myInputXSLSource,
(XSLTResultTarget&) ...)


This portion of code works fine for the XML input source of the
XalanTransformer.transform(...). But if  I try to use it for the XSL input
source, the memory usage increase when transforming.

I precise that this behaviour appears only on Linux, not on W2K.

Some precisions :
All the source is in a shared library used by client code.

I compile with the -O -fpic -D_REENTRANT -DLINUX  -DNDEBUG options
All the shared library used (libxalan-c1_2.so and libxerces-c1_5_1.so) have
been compiled and linked under my development environment (gcc 2.96 &
Mandrake 8.0).


Do you believe that is a bug ?

Thanks

Olivier Moises


Generic Concept
94, Av Jean Lebas
59100 Roubaix
FRANCE
e-mail: contact@generic-concept.com

-----Message d'origine-----
De : David_N_Bertoni@lotus.com [mailto:David_N_Bertoni@lotus.com]
Envoye : vendredi 28 septembre 2001 16:33
A : contact@generic-concept.com
Objet : RE: XalanC XalanDOMString and memory release!


Olivier

I looked at your Windows project file and you are linking against the wrong
runtimes.  You must use either the debug Multithreaded DLL or Multithreaded
DLL runtime libraries.  This is why your application is crashing in release
mode.  This is well documented and is even a FAQ, so please make sure
you're linking correctly and test again.

As far as Linux is concerned, we've never had a single report of a
XalanDOMString memory leak in the processor.  Make sure you're using the
correct version of gcc if you're using our pre-built libraries.

As I explained in me previous email, XalanDOMString's implementation uses
std::vector.  XalanDOMString itself allocates _no_ memory, so if there's a
leak, it's in gcc's std::vector implementation and there's not much we can
do about it.

I'm extremely confident that there are no leaks in XalanDOMString.
Remember that runtime heap managers will often keep allocated memory cached
instead of returning it to the operating system.  This might explain the
behavior of the release version on Windows and the behavior under Linux.
You might also test just creating XalanDOMStrings on the stack to see if
that changes the way memory is used:

   for (int i=0; i < 1000000; ++i)
   {
        XalanDOMString    test;

       test.assign ("Hello");
   }

This is essentially the same test as far as leaks in XalanDOMString are
concerned.  Any application which dynamically allocates 1 million small
objects on the heap is going to have horrible run-time memory
characteristics.

Dave