感谢！我先改着测试下。出现概率低，但确实存在，很头疼。
希望有用
这就两句代码，看不出可被释放的过程，你说申请的内存指的是什么对象的内存？
我简单写一下
js_CanvasRenderingContext2D_setCanvasBufferUpdatedCallback这个函数里
调用Data_to_seval
调用createTypedArray
调用void* copiedData = malloc(byteLength);这里申请了一块内存
继续往下在这里JSObjectRef jsobj = JSObjectMakeTypedArrayWithBytesNoCopy(__cx, jscTypedArrayType, copiedData, byteLength, myJSTypedArrayBytesDeallocator, nullptr, &exception);生成了JSObjectRef jsobj这个对象
jsobj被放到Object* obj对象里return出来
被放到se::HandleObject obj里这里会root一下
然后obj被放到返回值ret里返回上一层
刚才的se::HandleObject obj这时候析构又unroot了一下，这时候刚才的jsobj是unroot状态
这个ret在外层是se::ValueArray args;里的args[0]，如下
ok &= Data_to_seval(larg0, &args[0]);
//log1
se::Value rval;
se::Object* thisObj = jsThis.isObject() ? jsThis.toObject() : nullptr;
se::Object* funcObj = jsFunc.toObject();
//log2
bool succeed = funcObj->call(args, thisObj, &rval);
这段代码在//log1和//log2之间也就是，最后一句代码内部执行JSObjectCallAsFunction之前。
有可能会释放之前malloc的copiedData的内存
我在JSObjectMakeTypedArrayWithBytesNoCopy这个函数的myJSTypedArrayBytesDeallocator这个函数里打了log，如下
static void myJSTypedArrayBytesDeallocator(void* bytes, void* deallocatorContext)
{
//log bytes的地址
free(bytes);
}
发现这个地址和刚才malloc的copiedData的地址是同一个地址
1赞
厉害了，如果检测到释放，那一定就是被释放了，能定位下释放时的堆栈吗？按理是同一线程，可以看出是什么原因释放的，我们这边试试能捕捉到这个崩溃不。
这个没测试了
没有在myJSTypedArrayBytesDeallocator这个函数里面打过断点，只是打了log输出free的地址
个人感觉像是js那边在gc
一个原因是因为输出这个地址free的log的时候，还会连续输出很多个其他地址free的log，像是释放了很多资源
另一个原因是因为这个bug出现的概率很低可能是要刚好赶上js gc的时机
只是猜测，oc和js交互这块儿确实是不太懂
根据这个猜测，我试了一下先root一下能不能临时解决问题，目前看像是解决了
重现这个崩溃需要找性能比较差内存比较小的设备会更容易点儿
最终大部分是挂在glTexImage2D那里了
下个项目准备用unity了，cocos现在都不管原生了
在报这个崩溃之前没改过cocos2dx-lite jsc这块代码。现在也仅仅是改了global_load_image这里。
我先观察线上版本还有没类似崩溃，然后再试试你说的这个修改
1赞
我们在 2.0.10 和 2.1.1 里面修复了大量的原生崩溃问题。这里描述的问题应该已经修复了，详见 https://github.com/cocos-creator/cocos2d-x-lite/pull/1716
但是2.0.10 beta1在IOS native上还是有出现奔溃啊
大佬，改了之后崩溃降低了么。。。我这里的项目情况是data转成Uint8Array之后，然后js调用data时，发现数据不一致，之后应该就闪退了。我自己4台机器自动挂机一天时间，才出现一次。应该是data携带的数据被释放了。
PR 链接 404
这个根本就没改好！jsb_global_load_image
