Atomcis Bad Access

General JUCE discussion
1

Whenever I quit my application I get a bad access error. The last 6 items from my stack trace are:

#0 0x00008a3a in juce::Atomic<int>::operator-- at juce_Atomic.h:339 #1 0x00007080 in juce::StringHolder::release at juce_String.cpp:162 #2 0x0000735b in juce::StringHolder::release at juce_String.cpp:168 #3 0x0000374d in juce::String::~String at juce_String.cpp:252 #4 0x0001a3e3 in ChallengeComponent::~ChallengeComponent at ChallengeComponent.cpp:392

ChallengeComponent is my custom component. The program makes it all the way to the end of ChallengeComponent’s destructor, then goes into the juce::String, StringHolder, etc.

The specific lilne in juce_Atomic that is causing the error is:

#elif JUCE_ATOMICS_GCC return (Type) __sync_add_and_fetch (&value, -1);

I have the latest JUCE, running on Mac OS 10.6.8, XCode 3.2.6. Any ideas?

2

Just a guess, but the only realistic way that the Atomic code can fail is if it is given an unaligned address. Perhaps one of your objects is getting freed twice?

3

I figured that, but then why would it make it all the way to the end of my destructor? Wouldn’t it have gotten tripped up on the actual offending object’s deallocation?

4

Do you have static objects with constructors and destructors? Perhaps its something related to destructors of objects with static storage duration.

5

No, it hasn’t got as far as trying to deallocate your object yet - before deallocating an object the compiler will obviously first delete its members, so this is exactly what you’d expect to see if you’re trying to delete a dangling pointer.

Use modern c++ allocation techniques and you won’t ever get this kind of problem!!

6

I know. Going back and converting to scoped pointers is on my to-do list. Problem solved. Thnx!