Hi Ben, I think the API ref is targeted at plugin developers, I got the described behaviour when running debug builds. The errors go away if you build your debug build against the release version of the crt (if using the correct runtime). But then I again I think that passing around chunks of memory and freeing them "at the other side" is a bad idea to start with.
I'm worried to hear that the problem also pops up on unixes. Nowdays most of our custom developments are Java based but in the past we build C api's that where mainly build and tested on Windows and then recompiled and tested on the unix boxes. But this kind of errors could produce leaks that would stay undetected on the unix versions....I hope BMC did it right in their native Java API parts :) Hugo On 5/29/07, Ben Chernys <[EMAIL PROTECTED]> wrote:
** 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___ __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
