Crash in iOS Atomics

MacOSX and iOS
1

I’ve resurrected an app that was fine in iOS, and now, it compiles and links, but crashes with EXC_BADACCESS at the first use on a set or get on an Atomic <uint64_t>.

The debugger ends up here: #elif JUCE_ATOMICS_GCC return sizeof (Type) == 4 ? castFrom32Bit ((int32) __sync_add_and_fetch ((volatile int32*) &value, 0)) : castFrom64Bit ((int64) __sync_add_and_fetch ((volatile int64*) &value, 0)); #endif

:oops: I am not on the tip - it would risk the Mac and Linux versions I’m trying to get out to change right now.

iOS SDK 4.3, targetting 4.2, ARMv7 optimized targets. Same issue on iPhone 4 and iPad 1.

Any clues?

Bruce

2

OK, so changed the Atomic to a uint32_t and it’s all tikkecty-boo.

Most odd. I have some other atomic 64-bit ints, but they’re probably not active in the iOS (cut-down) version.

Bruce

3

I’m using OSAtomicAdd64Barrier directly, shouldn’t Juce be using that rather than GCC built-ins on iOS?

4

There’s code in there that will use the OSAtomicAdd64Barrier stuff in iOS3.2 and earlier, but I was kind of assuming that if GCC didn’t complain when compiling a 64-bit built-in op for ARM, then it’s be reasonable to expect it to actually work, rather than just emitting some broken assembly that crashes!

If you look in the atomics code, there’s this bit:

#if (JUCE_IOS && (__IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_3_2 || ! defined (__IPHONE_3_2))) \ || (JUCE_MAC && (JUCE_PPC || __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 2))) #define JUCE_ATOMICS_MAC 1 // Older OSX builds using gcc4.1 or earlier

…which you could try changing to:

#if JUCE_IOS \ || (JUCE_MAC && (JUCE_PPC || __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 2))) #define JUCE_ATOMICS_MAC 1 // Older OSX builds using gcc4.1 or earlier

…and that would enable the OSX atomics instead?

5

Weird to resurrect this post, but I just got this exact crash when using a Atomic<double>.

iOS Device: iPhone 5
iOS version: 8.41
OSX: El Capitan / Xcode 7
JUCE 4.3.0

replacing it with a std::atomic<double> fixed it, but I think it really shouldn’t crash.

6

Have you got any code that’d reproduce the crash?

(Although TBH this will get fixed anyway, as we’ll soon be replacing the old implementation of the Atomic class with std::atomic on platforms where it’s available, and iOS is certainly one of them)

1 Like
7

I am really just storing / loading a Atomic as member variable of my global controller object so it should be pretty trivial to reproduce (it’s definitely not a dangling pointer / lifetime issue)

The code runs fine on all platforms (OS X, Windows, Linux & iOS 9+). I just noticed it when I tested it on my old iPhone running iOS 8.41 (on my iPad Pro with iOS 9 everything is smooth).