深入NSString stringWithFormat的EXC_BAD_ACCESS：
[英]EXC_BAD_ACCESS on deep NSString stringWithFormat:
问题描述
I'm writing a Mac OS (10.8.4) app using Xcode 5.1.1 just for my own use (to solve an Eight Off solitaire game when I get stuck), and I don't care about efficiency or memory usage. 
我正在使用Xcode 5.1.1编写Mac OS（10.8.4）应用程序，仅供我自己使用（以解决卡住时的“八关单人游戏”），我并不关心效率或内存使用情况。 It's a recursive program (it creates a tree of possible moves, recurses, creates the next move, etc.) so it needs a lot of memory (I've got 24 GB) and I've increased the stack (-Wl,-stack_size,0x4000000). 这是一个递归程序（它创建可能的动作树，递归，创建下一个动作等），因此需要大量内存（我有24 GB），并且增加了堆栈（-Wl，- STACK_SIZE，0x4000000）。 But, regardless of the stack size, I get EXC_BAD_ACCESS code=2, always at the same depth (about 170 levels), and it's always on a line that uses NSString stringWithFormat: such as: 但是，无论堆栈大小如何，我都得到EXC_BAD_ACCESS code = 2，始终处于相同的深度（大约170个级别），并且始终位于使用NSString stringWithFormat的一行上，例如：
NSString *temp = [NSString stringWithFormat:@"%d",value]; // value is an integer
The line has been executed just fine in all previous recursion levels. 该行已在之前的所有递归级别中正常执行。 If I remove that particular line, the exception happens at some other stringWithFormat line. 如果删除该特定行，则会在其他stringWithFormat行处发生异常。 It's as if NSString has its own limit, regardless of my stack size setting. 就像我的堆栈大小设置一样，NSString似乎有其自己的限制。 It was working earlier, when using garbage collection instead of ARC. 使用垃圾回收而不是ARC时，它可以更早地工作。 (Xcode wanted me to convert to ARC.) （Xcode希望我转换为ARC。）
I've checked for Zombies, but there aren't any objects being referenced on the error lines anyway. 我已经检查了僵尸，但无论如何在错误行上都没有引用任何对象。
Why might I be getting the EXC_BAD_ACCESS regardless of the stack size, and always on stringWithFormat:? 为什么无论堆栈大小如何，我都始终使用stringWithFormat：来获取EXC_BAD_ACCESS？
Adding crash log: 添加崩溃日志：
Process: EightOff Solver [11701]
Path: /Users/USER/Library/Developer/Xcode/DerivedData/EightOff_Solver-dqppnsumvcsujjflailrgqxogyij/Build/Products/Debug/EightOff Solver.app/Contents/MacOS/EightOff Solver
Identifier: com.yourcompany.EightOff_Solver
Version: 1.0
Code Type: X86-64 (Native)
Parent Process: launchd [179]
User ID: 501
Date/Time: 2014-06-25 01:38:46.581 -0500
OS Version: Mac OS X 10.8.4 (12E55)
Report Version: 10
Sleep/Wake UUID: 561695D4-0498-43DC-9B0E-9417A5D5120D
Interval Since Last Report: 60266 sec
Crashes Since Last Report: 2
Per-App Crashes Since Last Report: 9
Anonymous UUID: 96F16B3C-9A73-63C2-B5CD-11CC51CFE612
Crashed Thread: 1 Dispatch queue: com.apple.root.default-priority
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000100400ec8
VM Regions Near 0x100400ec8:
MALLOC_TINY 0000000100100000-0000000100400000 [ 3072K] rw-/rwx SM=PRV
--> STACK GUARD 0000000100400000-0000000100401000 [ 4K] ---/rwx SM=NUL stack guard for thread 1
Stack 0000000100401000-0000000100483000 [ 520K] rw-/rwx SM=COW thread 1
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8eb18686 mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8eb17c42 mach_msg + 70
2 com.apple.CoreFoundation 0x00007fff93d38233 __CFRunLoopServiceMachPort + 195
3 com.apple.CoreFoundation 0x00007fff93d3d916 __CFRunLoopRun + 1078
4 com.apple.CoreFoundation 0x00007fff93d3d0e2 CFRunLoopRunSpecific + 290
5 com.apple.HIToolbox 0x00007fff93a36eb4 RunCurrentEventLoopInMode + 209
6 com.apple.HIToolbox 0x00007fff93a36c52 ReceiveNextEventCommon + 356
7 com.apple.HIToolbox 0x00007fff93a36ae3 BlockUntilNextEventMatchingListInMode + 62
8 com.apple.AppKit 0x00007fff9a52a533 _DPSNextEvent + 685
9 com.apple.AppKit 0x00007fff9a529df2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
10 com.apple.AppKit 0x00007fff9a5211a3 -[NSApplication run] + 517
11 com.apple.AppKit 0x00007fff9a4c5bd6 NSApplicationMain + 869
12 com.yourcompany.EightOff_Solver 0x0000000100006ea2 main + 34 (main.m:13)
13 com.yourcompany.EightOff_Solver 0x0000000100001bc4 start + 52
Thread 1 Crashed:: Dispatch queue: com.apple.root.default-priority
0 libsystem_c.dylib 0x00007fff936c682d __vfprintf + 40
1 libsystem_c.dylib 0x00007fff936c4e16 vsnprintf_l + 254
2 libsystem_c.dylib 0x00007fff936bf462 snprintf_l + 127
3 com.apple.CoreFoundation 0x00007fff93d0ef3f __CFStringAppendFormatCore + 11199
4 com.apple.CoreFoundation 0x00007fff93d594fb _CFStringCreateWithFormatAndArgumentsAux + 107
5 com.apple.Foundation 0x00007fff9a03f13c +[NSString stringWithFormat:] + 170
6 com.yourcompany.EightOff_Solver 0x0000000100009b67 -[Card description] + 663 (Card.m:265)
7 com.yourcompany.EightOff_Solver 0x00000001000091f7 -[Card makeNewGameStates:] + 9031 (Card.m:211)
8 com.yourcompany.EightOff_Solver 0x0000000100005087 -[MyDocument recursiveOnGameState:depth:] + 6903 (MyDocument.m:1195)
9 com.yourcompany.EightOff_Solver 0x00000001000054b2 -[MyDocument recursiveOnGameState:depth:] + 7970 (MyDocument.m:1210)
10 com.yourcompany.EightOff_Solver 0x00000001000054b2 -[MyDocument recursiveOnGameState:depth:] + 7970 (MyDocument.m:1210)
... [deleted identical lines numbered 11 through 170]
171 com.yourcompany.EightOff_Solver 0x00000001000054b2 -[MyDocument recursiveOnGameState:depth:] + 7970 (MyDocument.m:1210)
172 com.yourcompany.EightOff_Solver 0x00000001000054b2 -[MyDocument recursiveOnGameState:depth:] + 7970 (MyDocument.m:1210)
173 com.yourcompany.EightOff_Solver 0x00000001000054b2 -[MyDocument recursiveOnGameState:depth:] + 7970 (MyDocument.m:1210)
174 com.yourcompany.EightOff_Solver 0x00000001000054b2 -[MyDocument recursiveOnGameState:depth:] + 7970 (MyDocument.m:1210)
175 com.yourcompany.EightOff_Solver 0x00000001000054b2 -[MyDocument recursiveOnGameState:depth:] + 7970 (MyDocument.m:1210)
176 com.yourcompany.EightOff_Solver 0x00000001000054b2 -[MyDocument recursiveOnGameState:depth:] + 7970 (MyDocument.m:1210)
177 com.yourcompany.EightOff_Solver 0x00000001000029c2 -[MyDocument startBackgroundThread] + 2706 (MyDocument.m:882)
178 com.apple.CoreFoundation 0x00007fff93d8f09c __invoking___ + 140
179 com.apple.CoreFoundation 0x00007fff93d8ef37 -[NSInvocation invoke] + 263
180 com.apple.Foundation 0x00007fff9a07da30 -[NSInvocationOperation main] + 34
181 com.apple.Foundation 0x00007fff9a075926 -[__NSOperationInternal start] + 684
182 com.apple.Foundation 0x00007fff9a07d0f1 __block_global_6 + 129
183 libdispatch.dylib 0x00007fff96ec4f01 _dispatch_call_block_and_release + 15
184 libdispatch.dylib 0x00007fff96ec10b6 _dispatch_client_callout + 8
185 libdispatch.dylib 0x00007fff96ec21fa _dispatch_worker_thread2 + 304
186 libsystem_c.dylib 0x00007fff93654d0b _pthread_wqthread + 404
187 libsystem_c.dylib 0x00007fff9363f1d1 start_wqthread + 13
Thread 2:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff8eb1ad16 kevent + 10
1 libdispatch.dylib 0x00007fff96ec3dea _dispatch_mgr_invoke + 883
2 libdispatch.dylib 0x00007fff96ec39ee _dispatch_mgr_thread + 54
Thread 3:
0 libsystem_kernel.dylib 0x00007fff8eb1a6d6 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff93654f4c _pthread_workq_return + 25
2 libsystem_c.dylib 0x00007fff93654d13 _pthread_wqthread + 412
3 libsystem_c.dylib 0x00007fff9363f1d1 start_wqthread + 13
Thread 4:
0 libsystem_kernel.dylib 0x00007fff8eb1a6d6 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff93654f4c _pthread_workq_return + 25
2 libsystem_c.dylib 0x00007fff93654d13 _pthread_wqthread + 412
3 libsystem_c.dylib 0x00007fff9363f1d1 start_wqthread + 13
Thread 5:
0 libsystem_kernel.dylib 0x00007fff8eb1a6d6 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff93654f4c _pthread_workq_return + 25
2 libsystem_c.dylib 0x00007fff93654d13 _pthread_wqthread + 412
3 libsystem_c.dylib 0x00007fff9363f1d1 start_wqthread + 13
Thread 6:
0 libsystem_kernel.dylib 0x00007fff8eb1a6d6 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff93654f4c _pthread_workq_return + 25
2 libsystem_c.dylib 0x00007fff93654d13 _pthread_wqthread + 412
3 libsystem_c.dylib 0x00007fff9363f1d1 start_wqthread + 13
Thread 1 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000208 rbx: 0x00007fff7ecb5a98 rcx: 0x00000001004014c0 rdx: 0x0000000100402d30
rdi: 0x0000000100401338 rsi: 0x00007fff7ecb5a98 rbp: 0x0000000100401250 rsp: 0x0000000100400e20
r8: 0x00000001004014c0 r9: 0x0000000000000003 r10: 0x0000000000000000 r11: 0x00000001004012b4
r12: 0x00000000000001ff r13: 0x0000000100401500 r14: 0x00000001004014c0 r15: 0x0000000100402d30
rip: 0x00007fff936c682d rfl: 0x0000000000010202 cr2: 0x0000000100400ec8
Logical CPU: 0
6/30/14 Edited to add: this only started happening when I upgraded Xcode to 5.1.1 (from 5.0). 2014年6月30日编辑添加：仅当我将Xcode升级到5.1.1（从5.0）时才开始发生。 Could it be due to a changed build setting? 可能是由于更改了构建设置吗？ (I don't know what they were before.) I'm using an iMac (late 2012) Intel Core i5, OS 10.8.4. （我之前不知道它们是什么。）我正在使用iMac（2012年末）英特尔酷睿i5，操作系统10.8.4。 Some of the settings are: Base SDK: Latest (I've tried restricting to 10.8); 其中一些设置包括：基本SDK：最新（我尝试将其限制为10.8）； Valid Architectures i386, x86_64 (I've tried having just i386 or just x86_64). 有效的架构i386，x86_64（我尝试过仅使用i386或x86_64）。 Deployment Target: 10.8. 部署目标：10.8。
7/1/14 Edited to add: I was using NSOperationQueue (with dispatch_async on the main queue for the UI operations). 2014年7月1日编辑添加：我正在使用NSOperationQueue（UI操作的主队列上带有dispatch_async）。 Removing the NSOperationQueue fixed the crash, but now I'm unable to get my UI to update (NSLog gives me some output). 删除NSOperationQueue可以解决崩溃问题，但是现在我无法更新UI（NSLog给了我一些输出）。 Executing my loop in a dispatch_async() with a background queue also crashes, and again no UI updates. 在带有后台队列的dispatch_async（）中执行我的循环也会崩溃，并且再次没有UI更新。 Apparently, background tasks have a resource limit related to NSString that I'm unable to change. 显然，后台任务具有与我无法更改的NSString相关的资源限制。 It crashes (always on creating an NSString) even if I don't update my UI. 即使我不更新我的UI，它也会崩溃（总是在创建NSString时）。
1 个解决方案
解决方案1
0 2017-06-04 04:41:53
The fact that your problem is solved by removing dispatch_async() and just running it on the main thread leads me to believe you are indeed running out of stack memory in the thread. 通过删除dispatch_async（）并仅在主线程上运行就可以解决您的问题，这使我相信您确实在该线程中耗尽了堆栈内存。 I just ran into a similar problem (EXC_BAD_ACCESS at the top of various functions in a deeply recursive set of functions), and was able to fix it by increasing the stack size. 我遇到了一个类似的问题（在深度递归的一组函数中，各个函数的顶部都是EXC_BAD_ACCESS），并且能够通过增加堆栈大小来解决此问题。 I didn't seem able to increase the size using those -Wl,-stack_size,... flags though, nor using NSThreads. 我似乎无法使用-Wl，-stack_size，...标志或使用NSThreads来增加大小。 (Perhaps that's why that didn't help you.) Instead I launched the thread using pthread_create(), first calling pthread_attr_setstacksize() on it. （也许这就是为什么这样对您没有帮助。）相反，我使用pthread_create（）启动了线程，首先在其上调用了pthread_attr_setstacksize（）。 Code example here: https://developer.apple.com/library/content/qa/qa1419/_index.html 此处的代码示例： https : //developer.apple.com/library/content/qa/qa1419/_index.html
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.