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 Alex Bereznyi <al...@grandcentral.com> on 2000/10/02 21:25:26 UTC
RE: xerces-c_1_2D.dll memory allocation problem
Hi David,
thanks for replying.
sorry to say, but you missed the point: I do use multi-threaded DLL runtime
library,
but multi-threaded is not the source of the problem - string allocated by
DOMString::transcode()
still can't be deleted in my app without a crash, because of the Windows
implementation of runtime heap for DLLs:
each DLL uses it's own runtime heap for 'new', and NOT the heap the EXE app
is using.
I have added a method to DOMString class, which does not return allocated
buffer:
/**
* puts a copy of the string (null terminated), transcoded to the local
code page into supplied buffer.
* if buffer is NULL, only needed buffer size is returned.
* if buffer is not NULL, number of chars copied (including
termination null) is returned
* If buffer is too small -1 is returned, and nothing is copied.
*/
int transcode(char *buffer, unsigned int buf_size) const;
to work around this for myself now. I'd like to have it added to xerces-c
release, as works around the bug and it's generally useful for performance
reasons too. However, the bug is still there, and as it's trivial to fix, I
hope it can be fixed soon.
I'd be happy to help if you'd like me to fix it.
As for the DLL benefits versus static library, every app has different
needs, and for me the app size is an issue,
so I'd rather use a static library as I link in very little, and xerces-c
DLL is huge.
Thanks, Alex
-----Original Message-----
From: David_N_Bertoni@lotus.com [mailto:David_N_Bertoni@lotus.com]
Sent: Friday, September 29, 2000 7:49 PM
To: xerces-c-dev@xml.apache.org
Subject: Re: xerces-c_1_2D.dll memory allocation problem
This is the most often asked question about DOMString::transcode(), or for
that matter, Xerces itself. Xerces is built using either the release or
debug multi-threaded DLL runtime library. Your application must be built
the same way. Whether you agree with it or not, this is by design, and is
not a bug.
Your solution of adding an explicit delete function will solve your
problem, but introduces others, the most problematic of which is now you
have a pointer which must be freed in a particular way. What if sometimes
I'm using a transcoded string return from DOMString::transcode() and other
times I'm using a string that I allocated myself? I can't do it without
the extra overhead of tracking how the memory was allocated.
I haven't used static link libraries much since DLLs and shared libraries
became common. To me, the advantages of dynamic libraries far outweigh the
disadvantages.
Dave
Alex Bereznyi
<alexber@grandce To:
"'xerces-c-dev@xml.apache.org'" <xe...@xml.apache.org>
ntral.com> cc: Bobby Beckmann
<bo...@12.com>, (bcc: David N Bertoni/CAM/Lotus)
Subject: xerces-c_1_2D.dll
memory allocation problem
09/29/2000 07:34
PM
Please respond
to xerces-c-dev
I just started using xerces-c_1_2D.dll (Xerces-C_1_2_0a-win32.zip)
and found a problem with DOMString::transcode() .
DOMString::transcode() returns a buffer pointer allocated by new,
which is supposed to be freed by user according to docs (docs don't say
how,
but one can guess to call to delete).
This only works on Unix.
The problem is that on Windows each DLL has it's own heap and an attempt to
free a pointer
allocated by another binary (dll or exe) results in a crash.
The only other choice is to let this memory leak, which is pretty bad too
;-)
The quick fix will be to add a trivial exported function to DLL which calls
delete, and update doc in DOMString.hpp.
Example: void deleteXercesBuffer(void *p) { delete p; }
this would let DLL users to safely delete all buffers allocated by DLL
(using new) and returned to user.
I suspect that there can be more places where same problem exist in
xerces-c_1_2D.dll , I just didn't have time to find out ;-)
The better fix would be to add some new overloaded DOMString::transcode()
which is NOT allocating buffer,
but uses user-supplied one. It is more flexible and can be faster if user
uses stack buffer.
I wrote one to fix current version, and I hope something like it will be
added to next release.
It also suprises me that Xercec-C is not available in a form of a regular
link library, instead of a DLL,
which will eliminate the whole problem. Are there any plans to have a link
library distribution?
Thanks, Alex
---------------------------------------------------------------------
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
****************************************************************************
**
This email message is for the sole use of the intended recipients(s)
and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact sender by
reply email and destroy all copies of original message.
Re: xerces-c_1_2D.dll memory allocation problem
Posted by Dean Roddey <dr...@charmedquark.com>.
Actually, that's not true. There is one heap manager *per* type of runtime.
If everyone uses the same runtime, everyone uses the same heap manager. If
you mix runtimes, you get multiple heaps and lots of bad things can happen
if you aren't careful.
--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com
"It takes two buttocks to make friction"
- African Proverb
----- Original Message -----
From: "Alex Bereznyi" <al...@grandcentral.com>
To: <Da...@lotus.com>
Cc: <xe...@xml.apache.org>; "Bobby Beckmann" <bo...@12.com>
Sent: Monday, October 02, 2000 12:25 PM
Subject: RE: xerces-c_1_2D.dll memory allocation problem
> Hi David,
>
> thanks for replying.
>
> sorry to say, but you missed the point: I do use multi-threaded DLL
runtime
> library,
> but multi-threaded is not the source of the problem - string allocated by
> DOMString::transcode()
> still can't be deleted in my app without a crash, because of the Windows
> implementation of runtime heap for DLLs:
> each DLL uses it's own runtime heap for 'new', and NOT the heap the EXE
app
> is using.
>
> I have added a method to DOMString class, which does not return allocated
> buffer:
>
> /**
> * puts a copy of the string (null terminated), transcoded to the
local
> code page into supplied buffer.
> * if buffer is NULL, only needed buffer size is returned.
> * if buffer is not NULL, number of chars copied (including
> termination null) is returned
> * If buffer is too small -1 is returned, and nothing is copied.
> */
> int transcode(char *buffer, unsigned int buf_size) const;
>
> to work around this for myself now. I'd like to have it added to xerces-c
> release, as works around the bug and it's generally useful for performance
> reasons too. However, the bug is still there, and as it's trivial to fix,
I
> hope it can be fixed soon.
>
> I'd be happy to help if you'd like me to fix it.
>
> As for the DLL benefits versus static library, every app has different
> needs, and for me the app size is an issue,
> so I'd rather use a static library as I link in very little, and xerces-c
> DLL is huge.
>
>
> Thanks, Alex
>
>
> -----Original Message-----
> From: David_N_Bertoni@lotus.com [mailto:David_N_Bertoni@lotus.com]
> Sent: Friday, September 29, 2000 7:49 PM
> To: xerces-c-dev@xml.apache.org
> Subject: Re: xerces-c_1_2D.dll memory allocation problem
>
>
>
> This is the most often asked question about DOMString::transcode(), or for
> that matter, Xerces itself. Xerces is built using either the release or
> debug multi-threaded DLL runtime library. Your application must be built
> the same way. Whether you agree with it or not, this is by design, and is
> not a bug.
>
> Your solution of adding an explicit delete function will solve your
> problem, but introduces others, the most problematic of which is now you
> have a pointer which must be freed in a particular way. What if sometimes
> I'm using a transcoded string return from DOMString::transcode() and other
> times I'm using a string that I allocated myself? I can't do it without
> the extra overhead of tracking how the memory was allocated.
>
> I haven't used static link libraries much since DLLs and shared libraries
> became common. To me, the advantages of dynamic libraries far outweigh
the
> disadvantages.
>
> Dave
>
>
>
>
>
> Alex Bereznyi
>
> <alexber@grandce To:
> "'xerces-c-dev@xml.apache.org'" <xe...@xml.apache.org>
> ntral.com> cc: Bobby Beckmann
> <bo...@12.com>, (bcc: David N Bertoni/CAM/Lotus)
> Subject: xerces-c_1_2D.dll
> memory allocation problem
> 09/29/2000 07:34
>
> PM
>
> Please respond
>
> to xerces-c-dev
>
>
>
>
>
>
>
>
>
> I just started using xerces-c_1_2D.dll (Xerces-C_1_2_0a-win32.zip)
> and found a problem with DOMString::transcode() .
>
> DOMString::transcode() returns a buffer pointer allocated by new,
> which is supposed to be freed by user according to docs (docs don't say
> how,
> but one can guess to call to delete).
> This only works on Unix.
>
> The problem is that on Windows each DLL has it's own heap and an attempt
to
> free a pointer
> allocated by another binary (dll or exe) results in a crash.
> The only other choice is to let this memory leak, which is pretty bad too
> ;-)
>
> The quick fix will be to add a trivial exported function to DLL which
calls
> delete, and update doc in DOMString.hpp.
> Example: void deleteXercesBuffer(void *p) { delete p; }
>
> this would let DLL users to safely delete all buffers allocated by DLL
> (using new) and returned to user.
>
> I suspect that there can be more places where same problem exist in
> xerces-c_1_2D.dll , I just didn't have time to find out ;-)
>
> The better fix would be to add some new overloaded DOMString::transcode()
> which is NOT allocating buffer,
> but uses user-supplied one. It is more flexible and can be faster if user
> uses stack buffer.
> I wrote one to fix current version, and I hope something like it will be
> added to next release.
>
> It also suprises me that Xercec-C is not available in a form of a regular
> link library, instead of a DLL,
> which will eliminate the whole problem. Are there any plans to have a link
> library distribution?
>
>
> Thanks, Alex
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
>
>
>
>
>
****************************************************************************
> **
> This email message is for the sole use of the intended recipients(s)
> and may contain confidential and privileged information.
> Any unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact sender by
> reply email and destroy all copies of original message.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>