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 (Created) (JIRA)" <xe...@xml.apache.org> on 2011/12/01 22:22:40 UTC
[jira] [Created] (XERCESC-1974) Memory leak occurs if an exception
is thrown in TranscodeToStr or TranscodeFromStr constructors
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
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
[jira] [Commented] (XERCESC-1974) Memory leak occurs if an
exception is thrown in TranscodeToStr or TranscodeFromStr constructors
Posted by "Lee Doron (Commented) (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13161226#comment-13161226 ]
Lee Doron commented on XERCESC-1974:
------------------------------------
By the way, two more notes. First, I noticed inconsistent usage of tabs and spaces for indentation in the transcode() methods. I didn't want to muddy up the patch with whitespace changes, but you might want to clean that up (I personally suggest spaces, but that can be a religious issue ;-) ).
Second, I also have a slightly different approach to fixing this, that I originally started out with. Instead of using a local ArrayJanitor<XMLByte> (or XMLCh) template object to shadow fString, I actually changed the type of fString from a simple pointer to ArrayJanitor<XMLByte>. This means a few more changes here and in TransService.hpp, but it lets ArrayJanitor do more of the work.
It's really just a matter of style -- both approaches work equally well. If you want to keep the changes to a minimum, this patch is the one you want; if you want to clean up a bit, my other fix might be worth considering. Let me know if you're interested, and I will gladly post that as a patch, too.
> 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
> Labels: patch
> Fix For: 3.1.2, 3.2.0, 4.0.0
>
> Attachments: TransService.cpp.patch
>
> 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
[jira] [Updated] (XERCESC-1974) Memory leak occurs if an exception
is thrown in TranscodeToStr or TranscodeFromStr constructors
Posted by "Lee Doron (Updated) (JIRA)" <xe...@xml.apache.org>.
[ 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
[jira] [Updated] (XERCESC-1974) Memory leak occurs if an exception
is thrown in TranscodeToStr or TranscodeFromStr constructors
Posted by "Lee Doron (Updated) (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lee Doron updated XERCESC-1974:
-------------------------------
Attachment: TransService.cpp.patch
This patch is from the latest checked-in code in the development head of src/xercesc/util/TransService.cpp (revision 1138012).
> 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
> Labels: patch
> Fix For: 3.1.2, 3.2.0, 4.0.0
>
> Attachments: TransService.cpp.patch
>
> 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
[jira] [Updated] (XERCESC-1974) Memory leak occurs if an exception
is thrown in TranscodeToStr or TranscodeFromStr constructors
Posted by "Lee Doron (Updated) (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lee Doron updated XERCESC-1974:
-------------------------------
Labels: patch (was: )
> 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
> Labels: patch
> Fix For: 3.1.2, 3.2.0, 4.0.0
>
> Attachments: TransService.cpp.patch
>
> 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
[jira] [Commented] (XERCESC-1974) Memory leak occurs if an
exception is thrown in TranscodeToStr or TranscodeFromStr constructors
Posted by "Lee Doron (Commented) (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176235#comment-13176235 ]
Lee Doron commented on XERCESC-1974:
------------------------------------
I see you implemented my other suggestion, and, interestingly, your code is almost identical to mine! There is one tip I can pass along. I see you disabled a Microsoft warning in Xerces_autoconf_config.msvc.hpp. The warning is actually useful in some cases -- see http://www.unknownroad.com/rtfm/VisualStudio/warningC4251.html , http://support.microsoft.com/kb/q168958/ , http://www.eggheadcafe.com/microsoft/VC-Language/30952961/a-solution-to-warning-c4251--class-needs-to-have-dllinterface.aspx , and a few StackOverflow entries. Apparently, there's no perfect solution for this issue, but I avoided the warning by adding the following lines to TransService.hpp, just before the declaration of class TranscodeToStr:
// Perform explicit instantiations of the ArrayJanitor template as used by
// classes TranscodeToStr and TranscodeFromStr, respectively, with the
// XMLUTIL_EXPORT specifier. This forces all members of the class to be
// generated (and exported if appropriate), and avoids MSVC warning C4251.
template class XMLUTIL_EXPORT ArrayJanitor<XMLByte>;
template class XMLUTIL_EXPORT ArrayJanitor<XMLCh>;
However, I now notice that I left out using something like the EXPIMP_TEMPLATE macro that Microsoft has in their sample code. Perhaps, being much more familiar with the Xerces code than I am, you can decide on the best approach.
Anyway, this certainly does fix the memory leak. Thanks, and Happy New Year!
> 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
> Assignee: Alberto Massari
> Labels: patch
> Fix For: 3.2.0
>
> Attachments: TransService.cpp.patch
>
> 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
[jira] [Resolved] (XERCESC-1974) Memory leak occurs if an exception
is thrown in TranscodeToStr or TranscodeFromStr constructors
Posted by "Alberto Massari (Resolved) (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alberto Massari resolved XERCESC-1974.
--------------------------------------
Resolution: Fixed
Fix Version/s: (was: 3.1.2)
(was: 4.0.0)
Assignee: Alberto Massari
Fix is in SVN. Please verify.
> 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
> Assignee: Alberto Massari
> Labels: patch
> Fix For: 3.2.0
>
> Attachments: TransService.cpp.patch
>
> 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
[jira] [Updated] (XERCESC-1974) Memory leak occurs if an exception
is thrown in TranscodeToStr or TranscodeFromStr constructors
Posted by "Lee Doron (Updated) (JIRA)" <xe...@xml.apache.org>.
[ 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