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 "Lee Doron (Updated) (JIRA)" <xe...@xml.apache.org> on 2011/12/01 22:24:39 UTC
[jira] [Updated] (XERCESC-1974) Memory leak occurs if an exception
is thrown in TranscodeToStr or TranscodeFromStr constructors
[ https://issues.apache.org/jira/browse/XERCESC-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lee Doron updated XERCESC-1974:
-------------------------------
Description:
The constructor for TranscodeToStr calls TranscodeToStr::transcode(). That method allocates memory for fString, but it is possible for an exception to occur shortly thereafter; it might be thrown directly by transcode(), or by the transcoder method call trans->transcodeTo(). Since we are still in the constructor, TranscodeToStr's destructor will not be called during the stack unwind to clean up (see <http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.10>). Therefore, we have to explicitly make sure fString will be deallocated. Since the current code doesn't do that, it leaks memory. TranscodeFromStr is in the same situation.
I have a simple patch that I expect to post later tonight.
was:
The constructor for TranscodeToStr calls TranscodeToStr::transcode(). That method allocates memory for fString, but it is possible for an exception to occur shortly thereafter; it might be thrown directly by transcode(), or by the transcoder method call trans->transcodeTo(). Since we are still in the constructor, TranscodeToStr's destructor will not be called during the stack unwind to clean up (see http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.10). Therefore, we have to explicitly make sure fString will be deallocated. Since the current code doesn't do that, it leaks memory. TranscodeFromStr is in the same situation.
I have a simple patch that I expect to post later tonight.
> Memory leak occurs if an exception is thrown in TranscodeToStr or TranscodeFromStr constructors
> -----------------------------------------------------------------------------------------------
>
> Key: XERCESC-1974
> URL: https://issues.apache.org/jira/browse/XERCESC-1974
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 3.1.1
> Environment: Any
> Reporter: Lee Doron
> Fix For: 3.1.2, 3.2.0, 4.0.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The constructor for TranscodeToStr calls TranscodeToStr::transcode(). That method allocates memory for fString, but it is possible for an exception to occur shortly thereafter; it might be thrown directly by transcode(), or by the transcoder method call trans->transcodeTo(). Since we are still in the constructor, TranscodeToStr's destructor will not be called during the stack unwind to clean up (see <http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.10>). Therefore, we have to explicitly make sure fString will be deallocated. Since the current code doesn't do that, it leaks memory. TranscodeFromStr is in the same situation.
> I have a simple patch that I expect to post later tonight.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org