BAD ACCESS after closing PluginGui ComponentAnimator(64,MAC)

General JUCE discussion
1

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::timer::TimerThread::callTimers at juce_Timer.cpp:125
#7 0x12c90be62 in juce::timer::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

2

Um… Component Animator does use a WeakPointer! I’m not sure how you’d manage to make it go wrong…?

3

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 :smiley: 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!

4

When you delete the ComponentAnimator, it deletes any animations that are running, so surely that should be getting cleaned up when you quit?

5

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?

6

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…