Large POD struct copy to stack crashes in a worker thread - ios

Question

iOS project in a mix of Obj-C++ and C++ proper. I have a POD struct about 1 MB in size. There is a global instance of it. If I create a local instance of the same in a function that is invoked on a worker thread, the copy operation crashes (when invoked from a worker thread) in debug builds on a simulator. The release builds don't crash.
This smells like running out of stack size.
The worker thread in question is not created manually - is an NSOperationQueue worker.
The questions are twofold:
why does automatic stack growth fail?
how does one increase stack size on NSOperationQueue threads?
The repro goes:
struct S
{
char s[1024*1024];
};
S gs;
-(void)f
{
S ls;
ls = gs; //Crash!
}
Okay, I see about rewriting NSOperationQueue to grow the stack. That said - the **compiler (Clang) definitely has some kind of workaround for that. I'll check the disassembly just in case, but the same code doesn't crash in release builds. How come it's not engaging in this case? OBTW, checked the same code on Android, saw same crash.
PS: the motivating case is from not from my code, it's from a third party algorithm library. The original library doesn't really need a deep copy; the local variable is never written to, only read from; a reference (even a const one) would do just as well. My guess is that the author wanted a reference but messed it up. In the release build, the compiler optimizes is to a reference, thus no crash. In the debug build, it does not.

Answer 1

I don't know how up to date this documentation is, but according to Apple non-main threads top out at 512kiB stack size unless otherwise configured during thread creation.
I struggle to see a good reason to store such a data structure on the stack, particularly with (Obj-)C++ where you can easily wrap it in something like a std::unique_ptr which manages heap allocations and deallocations automatically. (Or indeed any other RAII based abstraction, or even storing it as an ivar in an ARC-enabled Objective-C class if you're so inclined.)
One downside to opting into very large stack sizes is that this memory likely stays resident but unused until the thread terminates, particularly on iOS where this memory won't even be swapped to disk. This is fine if you're explicitly starting up a thread and shut it down once you're done with your giant-stack-requiring-algorithm. But if you're running a one-off job on a pooled thread, you've now effectively leaked 1MB of memory. Maybe it's the embedded developer in me (or that I remember when iPhones only had 128MB RAM) but I'd prefer not to write code like that. (Or can someone come up with evidence that the low-memory warning mechanism purges unused stack space?)

Answer 2

Under the hood the threading mechanism of Cocoa uses unix POSIX threads for which stack size follows the following rules:
Default stack size, if it's not explicitly specified (e.g. in macOS you can find this value by running ulimit -s command, which for my machine is 8192 KiB, but for iOS is very likely a few times less)
Arbitrary stack size if it's specified during creating of a thread
Answering your first question:
why does automatic stack growth fail?
It "fails" because it's not allowed to grow beyond the allocated size for a given thread. More interesting question in this case - why it doesn't fail for release build? And frankly I don't have an answer here. I assume it most likely has something to do with the optimisation, where the compiler is allowed to bypass certain memory flow routines or discard some parts of code completely.
For the second question:
how does one increase stack size on NSOperationQueue threads?
The main thread of an application always has the default system stack size, and can only be altered in macOS (or rooted iOS device) with use of ulimit (size is given in KiB):
# Sets 32 MiB default stack size to a thread
% ulimit -s 32768
All other threads (to my knowledge) under both iOS and macOS have their size specified explicitly and it equals to 512 KiB. You will have to somehow forward the stack size to the pthread_create(3) function for them, something like this:
#import <Foundation/Foundation.h>
#import <pthread.h>
struct S {
char s[1024 * 1024];
};
void *func(void *context) {
// 16 MiB stack variable
S s[16];
NSLog(#"Working thread is finished");
auto* result = new int{};
return result;
}
int main(int argc, const char * argv[]) {
pthread_attr_t attrs;
auto s = pthread_attr_init(&attrs);
// Allocates 32 MiB stack size
s = pthread_attr_setstacksize(&attrs, 1024 * 1024 * 32);
pthread_t thread;
s = pthread_create(&thread, &attrs, &func, nullptr);
s = pthread_attr_destroy(&attrs);
void* result;
s = pthread_join(thread, &result);
if (s) {
NSLog(#"Error code: %d", s);
} else {
NSLog(#"Main is finished with result: %d", *(int *)result);
delete (int *)result;
}
#autoreleasepool {
}
return 0;
}
Unfortunately neither of queue API (GCD or NSOperation) exposes allocation part of their thread pools, let alone that NSThread doesn't let you to specify your own pthread explicitly for underlying execution. If you want to rely on those APIs, you will have to implement it "artificially".
Sample NSOperation subclass with arbitrary stack size thread
The interface of such a class can look something like this (provided the thread's stack size is constant and is not supposed to be an injected dependency):
// TDWOpeartion.h
#import <Foundation/Foundation.h>
NS_ASSUME_NONNULL_BEGIN
typedef void(^TDWOperationBlock)(void);
__attribute__((__objc_direct_members__))
#interface TDWOperation: NSOperation
#property (copy, nonatomic, readonly) TDWOperationBlock executionBlock;
- (instancetype)initWithExecutionBlock:(TDWOperationBlock)block NS_DESIGNATED_INITIALIZER;
#end
NS_ASSUME_NONNULL_END
The implementation file:
// TDWOpeartion.mm
#import "TDWOpeartion.h"
#import <pthread.h>
#define EXECUTE_WITH_ERROR(codeVar, execution) if((codeVar = execution)) {\
NSLog(#"Failed to execute " #execution " with error code: %d", codeVar);\
return;\
}
NS_ASSUME_NONNULL_BEGIN
__attribute__((__objc_direct_members__))
#interface TDWOperation ()
#property (assign, getter=tdw_p_isThreadStarted) BOOL tdw_p_threadStarted;
#property (assign, nonatomic) pthread_t tdw_p_underlyingThread;
#property (strong, nonatomic, readonly) dispatch_queue_t tdw_p_productsSyncQueue;
#end
NS_ASSUME_NONNULL_END
#implementation TDWOperation
#synthesize tdw_p_threadStarted = _tdw_p_threadStarted;
#pragma mark Lifecycle
- (instancetype)initWithExecutionBlock:(TDWOperationBlock)block {
if (self = [super init]) {
_executionBlock = block;
_tdw_p_threadStarted = NO;
_tdw_p_productsSyncQueue = dispatch_queue_create("the.dreams.wind.property_access.TDWOperation.isThreadStarted",
DISPATCH_QUEUE_CONCURRENT);
}
return self;
}
- (instancetype)init {
return [self initWithExecutionBlock:^{}];
}
#pragma mark NSOperation
- (void)main {
pthread_attr_t attrs;
int statusCode;
EXECUTE_WITH_ERROR(statusCode, pthread_attr_init(&attrs))
// Allocates 32 MiB stack size
EXECUTE_WITH_ERROR(statusCode, pthread_attr_setstacksize(&attrs, 1024 * 1024 * 32))
pthread_t thread;
EXECUTE_WITH_ERROR(statusCode, pthread_create(&thread, &attrs, &tdw_p_runExecutionBlock, (__bridge_retained void *)self))
EXECUTE_WITH_ERROR(statusCode, pthread_attr_destroy(&attrs))
void* result = nullptr;
if (!self.cancelled) {
self.tdw_p_threadStarted = YES;
EXECUTE_WITH_ERROR(statusCode, pthread_join(thread, &result));
self.tdw_p_threadStarted = NO;
}
NSLog(#"Main is finished with result: %d", *(int *)result);
delete (int *)result;
}
#pragma mark Properties
- (void)setExecutionBlock:(TDWOperationBlock)executionBlock {
if (self.tdw_p_isThreadStarted) {
[NSException raise:NSInternalInconsistencyException
format:#"Cannot change execution block when execution is already started"];
}
_executionBlock = executionBlock;
}
- (BOOL)tdw_p_isThreadStarted {
__block BOOL result;
dispatch_sync(_tdw_p_productsSyncQueue, ^{
result = _tdw_p_threadStarted;
});
return result;
}
- (void)setTdw_p_threadStarted:(BOOL)threadStarted {
dispatch_barrier_async(_tdw_p_productsSyncQueue, ^{
self->_tdw_p_threadStarted = threadStarted;
});
}
#pragma mark Private
void *tdw_p_runExecutionBlock(void *args) {
TDWOperation *self = (__bridge_transfer TDWOperation *)args;
if (self.executionBlock) {
self.executionBlock();
}
int *result = new int{};
return result;
}
#end
And now you can use it just like a regular NSOperation instance:
#import "TDWOpeartion.h"
#include <type_traits>
struct S {
unsigned char s[1024 * 1024];
};
int main(int argc, const char * argv[]) {
#autoreleasepool {
NSOperationQueue *queue = [NSOperationQueue new];
[queue addOperations:#[
[[TDWOperation alloc] initWithExecutionBlock:^{
using elemType = std::remove_all_extents_t<decltype(S::s)>;
S arr[16];
auto numOfElems = sizeof(S::s) / sizeof(elemType);
for(decltype(numOfElems) i = 0; i < numOfElems; ++i) {
for (auto val: arr) {
val.s[i] = i % sizeof(elemType);
}
}
NSLog(#"Sixteen MiB were initialized");
}]
] waitUntilFinished:YES];
}
return 0;
}