Hi Hugo, As I said, I got exactly the same results on a Sun sparc running Solaris 5.9 with and without ElectricFence (a free malloc replacement that is used to debug malloc issues - will work with Linux!). This will tend to rule out anything to do with msvcrt.dll versions although certainly this smacks of the same problem. The problem seems to be a stack hit that tends to wipe out a return address and cause other random effects. As for the API Ref's comment, my debug versions were not blowing up, the non-debug versions were. Albeit all are made with the wrong versions of VS but with the recommended libs. Anyhow, getting similar symptoms on a different box and OS would, as I said, tend to rule out this. And yes, my workaround would also be work for the reasons you're hinting at. Cheers Ben
_____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Hugo Visser Sent: May 29, 2007 10:19 AM To: [email protected] Subject: Re: Problem with function FreeARQualifierStruct ** Most likely you are compiling against a different msvcrt version then the Remedy API is compiled against. I've run in to this when writing plugins, aparently it's also an issue with "normal" API's. What happens is that somewhere along the line the Remedy API allocates some memory. But since the API is compiled against a different msvcrt, the memory is allocated from a different heap. When you try to free the pointer to the allocated memory in your program, the memory region cannot be free'd because it wasn't allocated on your own heap. When coding plugins, the server will pass in a struct and you should allocate memory that the server attempts to free. At this point the same problems will occur. If you provide your own FreeAR* equivalents you should be fine, since you are managing your own heap again. Unfortunately the versions of msvcrt are tied to the versions of Visual Studio. VS 6 will use msvcrt.dll, VS.NET will use msvcrt7.dll (or something like that) etc. The C API guide has a comment about the versions of Visual Studio you should use for a particular version of the API, to prevent heap allocation problems. I'm not sure if this is also a problem on unix platforms, but I don't think so as the libc is a system component on unix, so every api that links to libc uses the same heap, if linked dynamically. Hugo On 5/29/07, Ben Chernys <[EMAIL PROTECTED]> wrote: ** As I said, I don't understand it. I just know that since I made that change, I am 100% stable again. I do not know the intimate details of the driver source though I (of-course) have looked at it and even use it (the binary) on occasion. I certainly haven't made it for ages! If you do find some underlying reason, I would appreciate knowing about it. But as an experiment, just comment out your Free() call when you do the malloc'ing and see what happens. Cheers Ben _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Beketov Danila Sent: May 29, 2007 9: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___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
