I’ve got plugin-gui which uses the ComponentAnimator here and there, it seems it accesses the GUI after the element is deleted.
Component Animator should use a WeakPointer
#0 0x103515d50 in ??
#1 0x12caa0269 in juce::Component::repaint at juce_Component.cpp:1782
#2 0x12caa8593 in juce::Component::setAlpha at juce_Component.cpp:1769
#3 0x12cc4572c in juce::ComponentAnimator::AnimationTask::useTimeslice at juce_ComponentAnimator.cpp:111
#4 0x12ca8aafc in juce::ComponentAnimator::timerCallback at juce_ComponentAnimator.cpp:329
#5 0x12ca8ac25 in non-virtual thunk to juce::ComponentAnimator::timerCallback() at juce_ComponentAnimator.cpp:340
#6 0x12c917ddc in juce::TimerThread::callTimers at juce_Timer.cpp:125
#7 0x12c90be62 in juce::TimerThread::CallTimersMessage::messageCallback at juce_Timer.cpp:196
#8 0x12c91612a in juce::MessageQueue::deliverNextMessage at juce_osx_MessageQueue.h:80
#9 0x12c91623d in juce::MessageQueue::runLoopCallback at juce_osx_MessageQueue.h:90
#10 0x12c915e68 in juce::MessageQueue::runLoopSourceCallback at juce_osx_MessageQueue.h:99
#11 0x7fff831743d1 in __CFRunLoopDoSources0
#12 0x7fff831725c9 in __CFRunLoopRun
#13 0x7fff83171d8f in CFRunLoopRunSpecific
#14 0x7fff892d17ee in RunCurrentEventLoopInMode
#15 0x7fff892d1551 in ReceiveNextEventCommon
#16 0x7fff892d14ac in BlockUntilNextEventMatchingListInMode
#17 0x7fff820b2eb2 in _DPSNextEvent
#18 0x7fff820b2801 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
#19 0x7fff8207868f in -[NSApplication run]
#20 0x10120804b in NSProApplicationMain
Um… Component Animator does use a WeakPointer! I’m not sure how you’d manage to make it go wrong…?
Just as a data point, I saw a similar issue a few weeks ago.
In my case, this was caused by someone hitting “Quit” on our application while the component animator was doing a fade-in or fade-out. The problem does NOT occur for us unless the fade is actually in progress while the Quit is happening.
I didn’t figure out a good way around this - it doesn’t seem easy to see if your component animator is still running a job - but since I’m the only one who ever saw it and since the results aren’t particularly bad for us (you crash instead of quitting) it’s marked as a low priority bug.
You might check to see if your animator is still operating when you close the PluginGui, and if so, stop it yourself by hand - not exactly sure how that is to be accomplished, report back if you get it!
When you delete the ComponentAnimator, it deletes any animations that are running, so surely that should be getting cleaned up when you quit?
Interesting… I just tried it a few times in the current version of my program and I “couldn’t replicate” it.
I haven’t changed any code in that area, and I’m absolutely sure I didn’t fix it deliberately - and I’m sure this did it before, I filed a bug against myself.
I’ve been tightening up all sorts of things as I go - making my locks tighter, conversely making sure that any possible variable accessed from multiple threads is locked if it needs to be - so it’s not impossible I was the cause and I inadvertently fixed it.
Could it be an issue with an older Juce? Has the Original Poster tried updating to the tip?
i using the latest tip, but I’ve used the Desktop::getInstance().getAnimator() . (Because i quickly replaced the old .fadeOutComponent method, with it)
I will try moving to a separte ComponentAnimater class per PluginWindow…