I may be wrong here so please feel free to correct me and guide me right if you can.
I’m using VS2012 and the latest tip. I have a problem with ScopedPointer in debug builds. Why? Because it’s customary by the CRT to fill deleted Heap memory with 0xfeeefeee as an aid to the developer during debugging.
The problem that occurs frequently for me is in juce_Component.h
in the Component::internalRepaintUnchecked member:
if (cachedImage != nullptr)
The check against nullptr works great in a release build but in my debug build, this is sometimes (how often I don’t know) 0xfeeefeee and hence the code is executed and things crash.
It should be said that I’m using timers at the time; if it matters.
Is there anything that I can do? Perhaps ScopedPointer can return nullptr even when the value of the object is 0xfeeefeee (although that feels like a ugly hack to mee.)
0xfeeefeee is used to mark freed memory, so it seems you deleted the ScopedPointer (not the ScopedPointer’s object) at another location.
[quote=“ckk”]0xfeeefeee is used to mark freed memory, so it seems you deleted the ScopedPointer (not the ScopedPointer’s object) at another location.
Well, this object is out of my control, so it’s not something that I did.
You say that maybe the ScopedPointer itself was deleted? Since ScopedPointer’s never supposed to be new/deleted, you would suggest that the object containing the ScopedPointer (in this case a Component)
was deleted? Next time this happens I’ll check if there are other members of the Component that are crazy. Thanks for the tip.
Your component object has been deleted. You’re using a dangling pointer.
That seem very strange since I’m not doing anything out of the ordinary. My feeling is that it’s a late timer that comes in and do stuff to the deleted Component. I’ll see if I can replicate this…
Beside, the check against nullptr is to make sure the timer isn’t acting on deleted Components? The check is faulty since it doesn’t recognize 0xfeeefeee
The Component it using the Desktop Animator, and the window is deleted before the animation is ended. I found that out just now.
Probably the problem lies in ComponentAnimator::AnimationTask::useTimeslice since it doesn’t check if the Component itself still exists when it acts on the Component pointer.
A call to Desktop::getInstance().getAnimator().cancelAllAnimations in the Component dtor seem to relieve the problem.