You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Hiroyuki Shimada <sh...@din.or.jp> on 2002/09/29 14:06:54 UTC
Memory Leak
Hello, everyone.
My name is Hiro. I am trying to use Xerces-C 2.1.0 with Borland C++
Builder 5 Update 1.
1. Project Files For Borland C++ Builder 5
I succeeded to make a project group file and project groups for
XercesLib.dll, samples and tests for it.
They works quite well.
The project files were converted the dsp files in the Project\Win32\VC6
directory with the VC++ Project Conversion Utility of the C++ Builder 5
and the project group file was created by the IDE of C++ Builder 5.
I would like to send the project group file and project files to
Xerces-C project or to publish the archive of them at my site so that
every Xerces-C user to be happy.
Please tell me what the best way for the project team and every user is.
2. Memory Leak
I found some memory leak problems in Xerces-C 2.1.0 by CodeGuard (a
mamory and resource checker accessorized in C++ Builder 5) while I made
and test the project group file and project files for C++ Builder 5.
For example in the RefVectorOf class template in the util\RefVectorOf.c.
When we add an element, we use:
template <class TElem> void RefVectorOf<TElem>::addElement(TElem* const toAdd)
{
ensureExtraCapacity(1);
fElemList[fCurCount] = toAdd;
fCurCount++;
}
and the destructor is:
template <class TElem> RefVectorOf<TElem>::~RefVectorOf()
{
if (fAdoptedElems)
{
for (unsigned int index = 0; index < fCurCount; index++)
delete fElemList[index];
}
delete [] fElemList;
}
When TElem is XMLCh, the destructor should release each element as:
delete[] fElemList[index];
I could fixed this problem to use an wrapper below such as:
RefVectorOf<ArrayWrapper<XMLCh> > fMember;
/**
* The ArrayWrapper class template is a very simple wrapper for the array
* created by the new[] operator and protects the memory leak of the array.
*
* The ArrayWrapper receives a pointer to the first element of an array
* created by the new[] operator with its constructor, and it release the
* array with the delete[] operator in its destructor.
*/
// interface
template<class TArray> class ArrayWrapper
{
private:
TArray *m_Array;
protected:
ArrayWrapper(const ArrayWrapper<TArray>& o);
virtual ArrayWrapper& operator=(const ArrayWrapper<TArray>& o);
public:
ArrayWrapper(TArray *Array);
virtual ~ArrayWrapper();
virtual TArray *GetPointer() const;
};
// ---------------------------------------------------------------------------
template <class TArray>
ArrayWrapper<TArray>::ArrayWrapper(TArray *Array)
: m_Array(Array)
{
}
template <class TArray>
ArrayWrapper<TArray>::~ArrayWrapper()
{
delete[] m_Array;
}
template <class TArray>
ArrayWrapper<TArray>::ArrayWrapper(const ArrayWrapper<TArray>& o)
{
}
template <class TArray>
ArrayWrapper<TArray>& ArrayWrapper<TArray>::operator=(const ArrayWrapper<TArray>& o)
{
return *this;
}
template <class TArray>
TArray *ArrayWrapper<TArray>::GetPointer() const
{
return m_Array;
}
// ---------------------------------------------------------------------------
Also the RefHashTableOf class template seems to have a memory leak
problem.
The put member function receive the key as void *, but the
RefHashTableOf never release the put key object.
I don't purchase the code so much yet, the put seems to receive either
new-ed object or not new-ed object. And the type of key is either array
such as an XMLCh* string or not array such as IdentityConstraint*
which points only one IdentityConstraint instance.
The RefHashTableOf is used in so many place that it is hard for me to
fix them...
----------------------------------------------------------------------
Mail: shimaden@din.or.jp
Home Page: http://www.din.or.jp/~shimaden/
Hiroyuki Shimada
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Memory Leak
Posted by Vitaly Prapirny <ma...@mebius.net>.
Tinny Ng wrote:
>
> Hiro,
>
> > 1. BCB5
>
> We had a set of BCB5 project files before, but just they are now out-of-date
> and thus are not distributed. You can find them from our CVS
> (http://cvs.apache.org/viewcvs.cgi/xml-xerces/c/Projects/Win32/BCB5/). So
> if you can submit your patch based on our structure, it is appreciated and
> we can just simply update them. Thanks!
>
But what the problem with mak-files from Bugzilla bug "[Bug 11974] -
mak-files
for bcc32 v.5.5.1 (free or from BCB5)" ? Why that files are not included
to
Xerces release ?
>
> Thanks!
>
> Tinny
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Projects for BCB5 (Re: Memory Leak)
Posted by Hiroyuki Shimada <sh...@din.or.jp>.
Hello, Tinny
On Mon, 30 Sep 2002 09:57:17 -0400
"Tinny Ng" <tn...@ca.ibm.com> wrote:
> > 1. BCB5
>
> We had a set of BCB5 project files before, but just they are now out-of-date
> and thus are not distributed. You can find them from our CVS
> (http://cvs.apache.org/viewcvs.cgi/xml-xerces/c/Projects/Win32/BCB5/). So
> if you can submit your patch based on our structure, it is appreciated and
> we can just simply update them. Thanks!
I published the set of BCB5 project files at
http://shimaden.homelinux.net/~shimaden/xercesc/
I am glad if it is useful for many poeple.
Thank you.
----------------------------------------------------------------------
Mail: shimaden@din.or.jp
Home Page: http://www.din.or.jp/~shimaden/
Hiroyuki Shimada
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Memory Leak
Posted by Tinny Ng <tn...@ca.ibm.com>.
Hiro,
> 1. BCB5
We had a set of BCB5 project files before, but just they are now out-of-date
and thus are not distributed. You can find them from our CVS
(http://cvs.apache.org/viewcvs.cgi/xml-xerces/c/Projects/Win32/BCB5/). So
if you can submit your patch based on our structure, it is appreciated and
we can just simply update them. Thanks!
> 2: Memory Leak
I think this is similar to the one reported in Bugzilla bug 9561
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9561). It is
appreciated if you can post your suggestion in that bugzilla bug, and we
will consider it once we are ready to fix this bug.
Thanks!
Tinny
----- Original Message -----
From: "Hiroyuki Shimada" <sh...@din.or.jp>
To: <xe...@xml.apache.org>
Sent: Sunday, September 29, 2002 8:06 AM
Subject: Memory Leak
> Hello, everyone.
>
> My name is Hiro. I am trying to use Xerces-C 2.1.0 with Borland C++
> Builder 5 Update 1.
>
> 1. Project Files For Borland C++ Builder 5
>
> I succeeded to make a project group file and project groups for
> XercesLib.dll, samples and tests for it.
> They works quite well.
>
> The project files were converted the dsp files in the Project\Win32\VC6
> directory with the VC++ Project Conversion Utility of the C++ Builder 5
> and the project group file was created by the IDE of C++ Builder 5.
>
> I would like to send the project group file and project files to
> Xerces-C project or to publish the archive of them at my site so that
> every Xerces-C user to be happy.
> Please tell me what the best way for the project team and every user is.
>
>
> 2. Memory Leak
>
> I found some memory leak problems in Xerces-C 2.1.0 by CodeGuard (a
> mamory and resource checker accessorized in C++ Builder 5) while I made
> and test the project group file and project files for C++ Builder 5.
>
> For example in the RefVectorOf class template in the util\RefVectorOf.c.
> When we add an element, we use:
>
> template <class TElem> void RefVectorOf<TElem>::addElement(TElem* const
toAdd)
> {
> ensureExtraCapacity(1);
> fElemList[fCurCount] = toAdd;
> fCurCount++;
> }
>
> and the destructor is:
>
> template <class TElem> RefVectorOf<TElem>::~RefVectorOf()
> {
> if (fAdoptedElems)
> {
> for (unsigned int index = 0; index < fCurCount; index++)
> delete fElemList[index];
> }
> delete [] fElemList;
> }
>
> When TElem is XMLCh, the destructor should release each element as:
>
> delete[] fElemList[index];
>
> I could fixed this problem to use an wrapper below such as:
>
> RefVectorOf<ArrayWrapper<XMLCh> > fMember;
>
> /**
> * The ArrayWrapper class template is a very simple wrapper for the array
> * created by the new[] operator and protects the memory leak of the
array.
> *
> * The ArrayWrapper receives a pointer to the first element of an array
> * created by the new[] operator with its constructor, and it release the
> * array with the delete[] operator in its destructor.
> */
>
> // interface
> template<class TArray> class ArrayWrapper
> {
> private:
> TArray *m_Array;
> protected:
> ArrayWrapper(const ArrayWrapper<TArray>& o);
> virtual ArrayWrapper& operator=(const ArrayWrapper<TArray>& o);
> public:
> ArrayWrapper(TArray *Array);
> virtual ~ArrayWrapper();
>
> virtual TArray *GetPointer() const;
> };
>
>
// -------------------------------------------------------------------------
--
> template <class TArray>
> ArrayWrapper<TArray>::ArrayWrapper(TArray *Array)
> : m_Array(Array)
> {
> }
>
> template <class TArray>
> ArrayWrapper<TArray>::~ArrayWrapper()
> {
> delete[] m_Array;
> }
>
> template <class TArray>
> ArrayWrapper<TArray>::ArrayWrapper(const ArrayWrapper<TArray>& o)
> {
> }
>
> template <class TArray>
> ArrayWrapper<TArray>& ArrayWrapper<TArray>::operator=(const
ArrayWrapper<TArray>& o)
> {
> return *this;
> }
>
> template <class TArray>
> TArray *ArrayWrapper<TArray>::GetPointer() const
> {
> return m_Array;
> }
>
// -------------------------------------------------------------------------
--
>
>
>
>
> Also the RefHashTableOf class template seems to have a memory leak
> problem.
> The put member function receive the key as void *, but the
> RefHashTableOf never release the put key object.
> I don't purchase the code so much yet, the put seems to receive either
> new-ed object or not new-ed object. And the type of key is either array
> such as an XMLCh* string or not array such as IdentityConstraint*
> which points only one IdentityConstraint instance.
>
> The RefHashTableOf is used in so many place that it is hard for me to
> fix them...
>
>
> ----------------------------------------------------------------------
> Mail: shimaden@din.or.jp
> Home Page: http://www.din.or.jp/~shimaden/
> Hiroyuki Shimada
> ----------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Memory Leak
Posted by Dean Roddey <dr...@charmedquark.com>.
There are already array/object heap janitor classes in Xerces, so no
need to add any.
-------------------------------------
Dean Roddey
The Charmed Quark Controller
droddey@charmedquark.com
www.charmedquark.com
-----Original Message-----
From: Hiroyuki Shimada [mailto:shimaden@din.or.jp]
Sent: Sunday, September 29, 2002 5:07 AM
To: xerces-c-dev@xml.apache.org
Subject: Memory Leak
Hello, everyone.
My name is Hiro. I am trying to use Xerces-C 2.1.0 with Borland C++
Builder 5 Update 1.
1. Project Files For Borland C++ Builder 5
I succeeded to make a project group file and project groups for
XercesLib.dll, samples and tests for it.
They works quite well.
The project files were converted the dsp files in the Project\Win32\VC6
directory with the VC++ Project Conversion Utility of the C++ Builder 5
and the project group file was created by the IDE of C++ Builder 5.
I would like to send the project group file and project files to
Xerces-C project or to publish the archive of them at my site so that
every Xerces-C user to be happy.
Please tell me what the best way for the project team and every user is.
2. Memory Leak
I found some memory leak problems in Xerces-C 2.1.0 by CodeGuard (a
mamory and resource checker accessorized in C++ Builder 5) while I made
and test the project group file and project files for C++ Builder 5.
For example in the RefVectorOf class template in the util\RefVectorOf.c.
When we add an element, we use:
template <class TElem> void RefVectorOf<TElem>::addElement(TElem* const
toAdd)
{
ensureExtraCapacity(1);
fElemList[fCurCount] = toAdd;
fCurCount++;
}
and the destructor is:
template <class TElem> RefVectorOf<TElem>::~RefVectorOf()
{
if (fAdoptedElems)
{
for (unsigned int index = 0; index < fCurCount; index++)
delete fElemList[index];
}
delete [] fElemList;
}
When TElem is XMLCh, the destructor should release each element as:
delete[] fElemList[index];
I could fixed this problem to use an wrapper below such as:
RefVectorOf<ArrayWrapper<XMLCh> > fMember;
/**
* The ArrayWrapper class template is a very simple wrapper for the
array
* created by the new[] operator and protects the memory leak of the
array.
*
* The ArrayWrapper receives a pointer to the first element of an array
* created by the new[] operator with its constructor, and it release
the
* array with the delete[] operator in its destructor.
*/
// interface
template<class TArray> class ArrayWrapper
{
private:
TArray *m_Array;
protected:
ArrayWrapper(const ArrayWrapper<TArray>& o);
virtual ArrayWrapper& operator=(const ArrayWrapper<TArray>& o);
public:
ArrayWrapper(TArray *Array);
virtual ~ArrayWrapper();
virtual TArray *GetPointer() const;
};
//
------------------------------------------------------------------------
---
template <class TArray>
ArrayWrapper<TArray>::ArrayWrapper(TArray *Array)
: m_Array(Array)
{
}
template <class TArray>
ArrayWrapper<TArray>::~ArrayWrapper()
{
delete[] m_Array;
}
template <class TArray>
ArrayWrapper<TArray>::ArrayWrapper(const ArrayWrapper<TArray>& o)
{
}
template <class TArray>
ArrayWrapper<TArray>& ArrayWrapper<TArray>::operator=(const
ArrayWrapper<TArray>& o)
{
return *this;
}
template <class TArray>
TArray *ArrayWrapper<TArray>::GetPointer() const
{
return m_Array;
}
//
------------------------------------------------------------------------
---
Also the RefHashTableOf class template seems to have a memory leak
problem.
The put member function receive the key as void *, but the
RefHashTableOf never release the put key object.
I don't purchase the code so much yet, the put seems to receive either
new-ed object or not new-ed object. And the type of key is either array
such as an XMLCh* string or not array such as IdentityConstraint*
which points only one IdentityConstraint instance.
The RefHashTableOf is used in so many place that it is hard for me to
fix them...
----------------------------------------------------------------------
Mail: shimaden@din.or.jp
Home Page: http://www.din.or.jp/~shimaden/
Hiroyuki Shimada
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org