iOS問題：出現(xiàn)崩潰問題饭入，崩潰定位在匯編而不是具體代碼
做一個軟件嵌器，當(dāng)接收到較大圖片時，軟件就會崩潰退出谐丢。而且定位在匯編爽航，而不是以往的代碼。
提示：
嘗試了靜態(tài)查找內(nèi)存泄漏乾忱，動態(tài)查找內(nèi)存泄漏讥珍，野指針，全局斷點等等窄瘟，都沒有找到具體問題所在衷佃，然后，我就用了最笨的一種方法蹄葱，一句一句代碼的篩查氏义，最后定位到了一句代碼。memcpy(signalCache + currentLoc, dataByte, data.length);
Byte signalCache[5000];
int currentLoc = 0;
@implementation SignalCache
+(void)addDataToSignalCache:(NSData *)data {
? ? Byte *dataByte = (Byte *)[data bytes];
? ? memcpy(signalCache + currentLoc, dataByte, data.length);
}
這里查一下 memcpy的使用就明白了图云，很簡單惯悠。memcpy()內(nèi)存操作函數(shù)可以完成一些數(shù)據(jù)的復(fù)制、賦值等操作竣况。查到原函數(shù)為void?memcpy(voiddest, const void *src, size_t n);功能是由src指向地址為起始地址的連續(xù)n個字節(jié)的數(shù)據(jù)復(fù)制到以dest指向地址為起始地址的空間內(nèi)克婶。source和destin所指內(nèi)存區(qū)域不能重疊，函數(shù)返回指向destin的指針。
我這里的問題就是destin的內(nèi)存區(qū)域留小了情萤，所以收到較大內(nèi)存時會崩潰鸭蛙。
//注意，source和destin都不一定是數(shù)組筋岛，任意的可讀寫的空間均可娶视。
發(fā)現(xiàn)是signalCache[5000]的5000小了，改為了8000就好了泉蝌。?
真的是很浪費時間的一個問題歇万。
參考：
這里是引用 https://blog.csdn.net/iteye_2449/article/details/82162957?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control&dist_request_id=a02df5b4-8c05-4afa-a7a1-ff547f50a5f9&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control
