Uploaded image for project: 'Log4cxx'
  1. Log4cxx
  2. LOGCXX-398

Infinite loop in Transcoder::encode(const LogString& src, std::wstring& dst)

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 0.10.0
    • Fix Version/s: 0.11.0
    • Component/s: Appender
    • Labels:
      None

      Description

      When building log4cxx as multi byte instead of wchar_t there's a bug in Transcoder::encode(const LogString& src, std::wstring& dst).

       

      void Transcoder::encode(const LogString& src, std::wstring& dst) {
       #if LOG4CXX_LOGCHAR_IS_WCHAR_T
       dst.append(src);
       #else
       for(LogString::const_iterator i = src.begin();
       i != src.end()
      { unsigned int cp = Transcoder::decode(src, i); encode(cp, dst); }
      #endif
       }
      

       

      If you pass an invalid multibyte string for src the Transcoder::decode function will return 0xffff and not advance the iterator i. The encode will then stick cp into dst over and over. Depending on whether your 32bit or 64bit you either get a crash when you blow past your 2/4 GB address space, or in 64bit you use up all available system resources and essentially lock up the OS.

      Here's the fix I've applied to my local version. It now does the same thing that Transcoder::decode() above it does, insert a LOSSCHAR and advance the iterator.

       

      void Transcoder::encode(const LogString& src, std::wstring& dst) {
       #if LOG4CXX_LOGCHAR_IS_WCHAR_T
       dst.append(src);
       #else
       for(LogString::const_iterator i = src.begin();
       i != src.end() {
       unsigned int cp = Transcoder::decode(src, i);
       if (cp != 0xFFFF)
      { encode(cp, dst); }
      else
      { dst.append(1, LOSSCHAR); i++; }
      }
       #endif
       }
      

       

        Attachments

          Activity

            People

            • Assignee:
              carnold@apache.org Curt Arnold
              Reporter:
              bhayes Brian Hayes
            • Votes:
              0 Vote for this issue
              Watchers:
              3 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