[function] rare crash on destroy
Hello,
In my application I use to "post" a pointer to a dynamically allocated
boost::function to a hidden window in the following manner (WinXP,
MSVC9.0, 1.41):
typedf function
Igor R wrote: ...
post() is called several times per second. Sometimes - but *very* rarely - the line "delete f" causes a crash (Access violation reading location 0xfeeefef6).
Wikipedia says that 0xFEEEFEEE is "Used by Microsoft's HeapFree() to mark freed heap memory".
Igor R wrote:
Wikipedia says that 0xFEEEFEEE is "Used by Microsoft's HeapFree() to mark freed heap memory".
Yes, and it's a begining of 72 bytes block of feeefeee. Apparently, it means that out_buffer.data was already freed. But I can't realize how it can be...
Is it possible that the free does not fail for the functor itself but for a member variable (for instance a pointer which is freed in the destructor)?
Is it possible that the free does not fail for the functor itself but for a member variable (for instance a pointer which is freed in the destructor)?
Well, first of all, the place where it crashes looks like an attempt to invoke the destructor of functor_type - it's not inside the destructor yet. The out_buffer looks like it's freed. Besides, my boost::function object contains the result of bind() with smart pointers only. Still, I've got one little doubt... Consider a smart-ptr that can be implicitly converted to the pointee (CComPtr), and a function that looks like this: func1(IMyInterface *obj); CComPtr<IMyInterface> ptr = ...; function f = bind(&func1, ptr); The binder will store the smart pointer itself, converting it in the place of the actuall call, right?
Igor R wrote:
Is it possible that the free does not fail for the functor itself but for a member variable (for instance a pointer which is freed in the destructor)?
Well, first of all, the place where it crashes looks like an attempt to invoke the destructor of functor_type - it's not inside the destructor yet. The out_buffer looks like it's freed.
Possible. I am not exactly fluent in assembler or in MSVC++ compile options. If you have some optimization on, you might not be able to see the exact line which actually crashes, I guess.
Besides, my boost::function object contains the result of bind() with smart pointers only.
Still, I've got one little doubt... Consider a smart-ptr that can be implicitly converted to the pointee (CComPtr), and a function that looks like this: func1(IMyInterface *obj);
CComPtr<IMyInterface> ptr = ...; function f = bind(&func1, ptr);
The binder will store the smart pointer itself, converting it in the place of the actuall call, right?
That sounds reasonable, but I am allergic to ComPtr ;-) If your own code is in charge of calling void post(const Functor &func) maybe you could wrap the functor in second functor which contains some information about the nature of "func". Maybe this will allow you to find out if only specific functors lead to the crash? Taking a stab in the dark... Regards, Roland
Solved. Just for the record: the issue arose due the "internals" of my functor (a race-condition occured between copies of a smart-pointer that wasn't set-up to be thread-safe).
participants (3)
-
Igor R -
Peter Dimov -
Roland Bock