I have designed some HttpClient and Socket classes which I implement for Linux and OSX using POCO classes, and which I implement for Windows using Microsoft libraries. These classes have been performing well, without problem, on all these environments. I decided it would be consistent if I used POCO to implement the classes on Windows also. This could be done as simply as changing a #define to so that the POCO implementation, instead of the Win32 implementation, was compiled and linked in on Windows, and since I had built a successful Windows demo program of classes that used POCO for a client recently, I thought the changeover would be straightforward.
Unfortunately when I run my code and it happens to go into Poco's Socket:: select, on returning from that function there is an exception thrown in a deallocate of a std::vector used internally by the Poco function. Now I know this doesn't necessarily mean there is a fault in Poco, it could be some subtle memory corruption in my own code that is causing the issue, but since this is established code for a large application that is running across a variety of environments without any problems, I am wondering if this isn't a build environment issue, some obvious problem that I may have overlooked. The details are: on Windows I build using Visual Studio 2005; Poco built using supplied cmd file; Linking dynamically; Same problem on debug and release mode builds ; Same problem whether memory checking macros on new and delete are turned on or off ; Build flags are matched to those of my application; Same problem whether linked to the latest stable release of poco, or the slightly earlier 1.4.3p1 that I am using; vector memory deallocation problem does not occur anywhere std::vector is used in my own code.
At least I can get into the poco code with the debugger, but before I do that I wonder if anyone else has come across this problem or can suggest something I might have forgotten to check.