XmlRpcValue destructor memory corruption?

[Brian Dobby]

Hi.
I'm running XML-RPC++ on Windows XP. When I run the debug build of my program, the heap manager sometimes (don't you love that word?) calls a debug break while processing the XmlRpcValue destructor. The destructor is trying to free a string from an array. A call to HeapValidate immediately before the destructor is called detects no errors. Anyone seen anything like this? Code sample follows.
  TIA
     Brian

        heapcheck();
        std::string strServiceName = CW2CT(m_bstrServiceName);
        std::string strRemoteName = CW2CT(bstrRemoteName);
        std::string strLocalName = CW2CT(bstrLocalName);
        XmlRpcValue args, result;
        args[0] = strServiceName.c_str();
        args[1] = strRemoteName.c_str();
        args[2] = strLocalName.c_str();
        ExecuteRequest("myserver.download", args, result);
        heapcheck();
        return S_OK;

[Brian Dobby]

More info.

Using the __CrtSetDbgFlag function to set _CRTDBG_CHECK_ALWAYS_DF, I have determined that the heap is detected as corrupt during XmlRpcClient::execute. A call to _CrtCheckMemory before calling XmlRpcClient::execute succeeds, a call following XmlRpcClient::execute fails.

The failure is detected in  the line _sources.erase(thisIt) in XmlRpc::XmlRpcDispatch::work()  Line 137.

The failure is very intermittent: sometimes I can run 5000 calls with no error, some times it fails on the first call to XmlRpcClient::execute, or the 11th call, or,,,,

Has anyone built anything that works with this library? On windows?

         Brian

[Cristian Ionescu]

I encountered this issue myself in a Windows Xp environment.
The debug breaks appear spuriously, and they are caused by the debug heap manager that reports that certain memory locations that were previously freed have been modified.
In my opinion these issues occur (in the debug heap manager) when the same memory locations are allocated and deallocated repeatedly. In my application, these blocks are relatively small (less than 200 bytes).
The workaround that I implemented was to re-enable the small-buffer heap (that from Windows 2000 is usually not active). I used the default value used for the older Windows OS - 1016 bytes.

#include <malloc.h>

    #define SMB_SIZE    1016U
    _set_sbh_threshold (SMB_SIZE);