[fdo-internals] Issues mixing vc9/vc10 runtimes and
FdoIoFileStream* Create(FILE* fp)
greg.boone at autodesk.com
Wed Mar 23 14:51:10 EDT 2011
Not that I am aware of. FDO should be fairly isolated in this regard. That being said, we need to run all the unit tests and perform system testing to ensure that is the case.
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Wednesday, March 23, 2011 2:19 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Issues mixing vc9/vc10 runtimes and FdoIoFileStream* Create(FILE* fp)
Will mixing and matching vc9 and vc10 binaries cause potential problems with memory allocators?
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: March 23, 2011 11:56 AM
To: FDO Internals Mail List (fdo-internals at lists.osgeo.org)
Cc: FDO Users Mail List (fdo-users at lists.osgeo.org)
Subject: [fdo-internals] Issues mixing vc9/vc10 runtimes and FdoIoFileStream* Create(FILE* fp)
Myself and Romy recently built the FDO binaries using vc9 and the FDO Unit Tests (and related CppUnit static lib) using vc10. This was done to mimic FDO usage within applications such as MapGuide, which may be compiled in vc10 in the near future.
Running unit tests on Win64/Release we see the following fatal error.
Microsoft Visual Studio C Runtime Library has detected a fatal error in UnitTest.exe.
> FDOCommon.dll!FdoIoFileStream::InitFileStatus() Line 394 C++
FDOCommon.dll!FdoIoFileStream::FdoIoFileStream() Line 78 C++
FDOCommon.dll!FdoIoFileStream::Create() Line 125 C++
UnitTest.exe!FdoIoTest::setUp() Line 49 C++
UnitTest.exe!CppUnit::TestCase::run() Line 27 C++
UnitTest.exe!CppUnit::TestSuite::run() Line 44 C++
UnitTest.exe!CppUnit::TextUi::TestRunner::runTest() Line 137 C++
UnitTest.exe!CppUnit::TextUi::TestRunner::runTestByName() Line 81 C++
UnitTest.exe!CppUnit::TextUi::TestRunner::run() Line 70 C++
UnitTest.exe!main() Line 91 C++
mFd = _fileno(mFp);
mFd = fileno(mFp);
struct stat fileStat;
if ( fstat(mFd, &fileStat) != 0 ) <<<<<<<<<<<<<<<<<<<<<<<<< Here <<<<<<<<<<<<<<<<<<
The problem is that in the unit test, the FILE* is opened using vc10, then in FDOCommon the vc9 version of fstat is used to access that pointer... and blammo, it dies.
// Create a file used for various file tests.
FILE* fp = fopen( "testFile.txt", "w" );
FdoIoFileStreamP fileStream = FdoIoFileStream::Create( fp );
fileStream->Write( (FdoByte*) "test file contents", 18 );
fileStream = NULL;
The problem API function is question is the following.
class FdoIoFileStream : public FdoIoStream
/// creates the stream around a C Runtime file stream.
/// \param fp
/// Input the file stream pointer.
/// Returns the created file stream.
FDO_API_COMMON static FdoIoFileStream* Create(FILE* fp);
My initial thought is to remove this method from the FDO API in 3.7.0.
The main purpose of the function is to allow an already opened FILE pointer (or stdin or stdout) to be wrapped in an FDO stream, usually for reading or writing XML. Streaming to or from stdout or stdin would likely be the most common case since the overload that takes a file name would more likely be used to access a disk file.
The only problem in removing it would be if a customer is calling it directly. I would almost say that this is unlikely but I suppose it is possible that someone is using it to stream XML from FDO to stdout.
Is there anyone using this method? Are there objections to removing it from the FDO API?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fdo-internals