Did you rebuild 'driver' in your environment (i.e. same compiler/IDE and OS etc) and run?? And it still runs without any errors? If so - your problem is most likely with the run-time library you're linking to - In Visual Studio .NET, ensure that your Project settings include -- Multi-threaded DLL (/MD) option (Right-click on your project node, Properties, C/C++ --> Code Generation --> Run-time library).
If the pre-built driver.exe given by BMC runs fine (built using VS.NET 2003), but not the one built on your machine (likely using VS.NET 2005)- likely the issue is due to the mismatch between the C runtime libraries. At this point I am not quite using VS.NET 2005. But we did see lot of problems when mixing up C runtimes (msvcrt60.dll, msvcrt70/71 etc) in the same process. Let me explain - in olden days when AR stuff was still being built using Visual Studio 6.0, when using those libraries in IDEs such as Visual Studio.NET 200? (which includes runtime msvcrt70.dll), Visual Studio.NET 2003 (msvcrt71.dll). The problem was that there are inherent incompatibilities in these libraries that you cannot safely allocate things by one runtime, handoff the allocated buffer to other runtime to free and vice-versa. This was a pretty widespread problem. Although I expect such issues would not exist with Vs.NET 2005 while using unmanaged DLLs built using VS.NET 2003. This expectation is based on the fact that VS.NET has evolved quite a bit and the leap from VS.NET 2003 to 2005 isn't that bad (i.e. when compared to VC 6 to VS.NET - all the managed/unmanaged etc etc too dramatic changes). In any case, if your experiment shows that the driver built in VS.NET2k5 exhibit problems - may be my expectation is wrong. Likely there are similar incompatibilities exist between using VS.NET 2003 built unmanaged DLLs from within VS.NET 2005. If this were the case, I suggest you to use VS.NET 2003 as your choice of IDE for developing AR solutions. BTW, I think I saw in other posts in this thread that de-allocation time problems occur on other platforms too. In that case, there indeed may be a bug in the your or BMC's code. It will help to see a code snippet beyond just the allocation and free statements alone, to guess what's wrong. BTW, if you comment all your code out except the QualifierStruct's initialization and ARFree, then run your code - do you get same problem?? Regards Appajee ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Beketov Danila Sent: Tuesday, May 29, 2007 12:41 AM To: [email protected] Subject: Re: Problem with function FreeARQualifierStruct But "driver" define qualifier in the same way (malloc), for example see function APIARGetListEntry in api.c, and FreeAR.. works without errors. Why ??? ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ben Chernys Sent: Tuesday, May 29, 2007 11:16 AM To: [email protected] Subject: Re: Problem with function FreeARQualifierStruct Addendum: I might add that the results are also consistent (in their inconsistency at least) on a different OS and hardware platform. One in which I can trap buffer overwrites, double frees and the like on the instruction that they occur. (see ElectricFence - unfortunately, not available for Windows). The only thing I can think is that the API is adjusting addresses or playing with a cache of some sort when allocating and freeing some of its objects. I would certainly consider this a bug in the API (BMC: hint hint). Cheers Ben __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
