Xerces-C++
  1. Xerces-C++
  2. XERCESC-1974

Memory leak occurs if an exception is thrown in TranscodeToStr or TranscodeFromStr constructors

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.2.0
    • Component/s: Utilities
    • Labels:
    • Environment:
      Any

      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.

        Activity

        Lee Doron created issue -
        Lee Doron made changes -
        Field Original Value New Value
        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.
        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&gt;). 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.
        Lee Doron made changes -
        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&gt;). 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.
        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.
        Lee Doron made changes -
        Attachment TransService.cpp.patch [ 12505812 ]
        Lee Doron made changes -
        Labels patch
        Alberto Massari made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Alberto Massari [ amassari ]
        Fix Version/s 4.0.0 [ 12314351 ]
        Fix Version/s 3.1.2 [ 12315014 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Alberto Massari
            Reporter:
            Lee Doron
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development