希望有用
这就两句代码,看不出可被释放的过程,你说申请的内存指的是什么对象的内存?
我简单写一下
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的地址是同一个地址
厉害了,如果检测到释放,那一定就是被释放了,能定位下释放时的堆栈吗?按理是同一线程,可以看出是什么原因释放的,我们这边试试能捕捉到这个崩溃不。
这个没测试了
没有在myJSTypedArrayBytesDeallocator这个函数里面打过断点,只是打了log输出free的地址
个人感觉像是js那边在gc
一个原因是因为输出这个地址free的log的时候,还会连续输出很多个其他地址free的log,像是释放了很多资源
另一个原因是因为这个bug出现的概率很低可能是要刚好赶上js gc的时机
只是猜测,oc和js交互这块儿确实是不太懂
根据这个猜测,我试了一下先root一下能不能临时解决问题,目前看像是解决了
重现这个崩溃需要找性能比较差内存比较小的设备会更容易点儿
最终大部分是挂在glTexImage2D那里了
下个项目准备用unity了,cocos现在都不管原生了
在报这个崩溃之前没改过cocos2dx-lite jsc这块代码。现在也仅仅是改了global_load_image这里。
我先观察线上版本还有没类似崩溃,然后再试试你说的这个修改
我们在 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
这个修改没有解决问题,只是降低崩溃概率。这个问题是由 JSC 过早GC TypedArray 对象导致的,目前能采取的解决方法就是使用 V8 替代 JSC。 可以尝试在 2.1+ , iOS 上使用 v8。 @qq317942417