adb devices设备offline，adb push file，Read-only file system

[ysh329]

当初还以为是和android10系统有关，搜了下没关系 后来发现adb push的时候用*匹配会有这个问题，如果单个文件上传adb push 不存在该问题

[ysh329]

無法使用 adb push file，Read-only file system http://www.mamicode.com/info-detail-2176636.html

无关解答，但是可以参考，需要root

adb devices设备offline

过了一会儿又好了

ADB出现devices offline的解决方法_运维_Dementors的博客-CSDN博客 https://blog.csdn.net/qq_33924155/article/details/79153000

[ysh329]

7HX5T19929012679    no permissions; see [http://developer.android.com/tools/device.html]
CUY0219604010390    no permissions; see [http://developer.android.com/tools/device.html]
NDF7N18818005475    no permissions; see [http://developer.android.com/tools/device.html]

[ysh329]

【问题现象】 APP内第一次预测opencl出检测框结果，但退出后再次进入不出结果（所有APP都有操作）。该问题不稳定复现。ADB shell环境无此问题。

【问题原因】 conv op的激活act_type没有初始化，导致APP里结果随机会加上RELU；

【排查方法】

1. 强化精度Profiler，确定问题层。增加打印每层OpenCL Buffer和Image结果，标明每层输出的tensor信息。便于与Fluid逐层比较结果，用以定位引入问题的层，并支持在安卓APP写结果到手机。 小结：定位到第一个conv1x1，因偶发，并不确定；
2. 定位conv问题。替换opencl conv为cpu的conv，发现结果正确，但又重新实现2种conv1x1。结果依旧不对。 小结：单测通过，问题依旧；
3. 二分commit，确定引入问题的commit。二分从今年年初到至今4个月的commit。 小结：以为找到问题commit，但实际该提交与opencl无关，只是出偶发错少一些；
4. 重新回顾opencl后端代码，对比MNN/MACE，排除底层问题： 用valgrind跑opencl单测/demo，修复definitly lost问题； 重新审视cl runtime和context关系，cl::kernel/cl::Program/cl::command_queue的资源问题并修复； 检查过程发现CLRuntime的单例创建问题，修复华为手机单测无法退出问题，间接发现paddle mobile的一个问题并解决。等等问题修复。 小结：修了一圈底层问题，但还未解决，怀疑不是conv1x1；
5. 修改pass的kernel选择策略，强行改第一个conv1x1走buffer实现的opencl kernel。 小结：修改后有其它问题；
6. 二分模型，缩小问题定义，简化问题。构建原模型的小（子）模型，向业务方要构造模型结构的代码，从大模型二分确定最小问题模型。化简为3层小模型，即原有模型前三层。 小节：化简原问题为3层小模型，关闭内存复用，根据打印信息在APP里打印结果重新定位，依然是第一个conv1x1；
7. 基于小模型，抽丝剥茧定位问题。kernel内取输入/权重/输出部分结果和均值，写回cpu。从后往前，排除kernel问题。手机观察出错结果时前后状态。定位到出错时，conv op的激活act_type值是不对的。 小结：定位到问题。 注：以上只列举关键流程，实际过程包括不限于以上。

【解决手段】

1. 修复conv op定义时未被初始化的act_type值，给初始值；
2. 修改判断conv是否加入激活的方式，并参考对比其他backends在激活判断的方式。

【解决效果】 修复后QA测试通过，计算正确APP上该问题不再出现，性能无影响。

【总结与启发】 ADB shell是一个理想环境，可以快速验证，但与安卓的底层环境不同，不能完全确保问题能完全复现，该问题在ADB shell环境不能复现。