DexFile.loadDex 挂起
任何 Android 专家都可以解释一下为什么这个方法会挂起?
当我暂停线程并查看堆栈时:
Thread [<13> Thread-15] (Suspended)
DexFile.openDexFile(String, String, int) line: not available [native method]
DexFile.<init>(String, String, int) line: 105
DexFile.loadDex(String, String, int) line: 144
Method.invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not available [native method]
Method.invoke(Object, Object...) line: 521
...您可以看到它挂在本机方法 DexFile.openDexFile 中,它永远不会返回。
这给我们正在编写的应用程序带来了严重的问题。它是随机发生的,因此表明多个线程之间存在某种竞争条件,但我连接了检测和死锁,而且我希望本机方法返回一些东西,即使是异常也很好!
提前致谢,
我正在使用 Android 2.2 Nexus One 设备,我正在将应用程序从 eclipse 部署到该设备。可以肯定的是,我完全卸载了该应用程序并重新启动设备,但我仍然随机看到上述问题。
更新:我在 Android 2.3.3 模拟器(API 10)上重试并遇到了同样的问题。我现在确信这里存在一个重大错误。我创建了一个简单的测试用例来显示问题。基本上我将一个dexified jar 添加到android 项目的assets 文件夹中。启动时,我将此文件复制到应用程序数据区域。然后,我启动 x 个线程,并在每个线程中使用 DexFile.loadDex 加载此 dexified jar 文件,但为生成的优化 dex 文件提供不同的输出文件名。如果您选择 x 为 30 个线程,那么您几乎肯定会看到多个线程挂起。
为了确保我重复了测试,每个线程都有自己独特的dexified jar 文件。出现同样的问题。
我看到的唯一 LogCat 输出可能会提示出现的问题:
02-23 11:59:23.097: DEBUG/dalvikvm(12598): DexOpt: sleep on folly(/data/dalvik-cache/system@[电子邮件受保护]@classes.dex) 02-23 11:59:23.138:调试/dalvikvm(12602):DexOpt:睡在羊群上(/data/dalvik-cache/system@[电子邮件受保护]@classes.dex) 02-23 11:59:23.357:调试/dalvikvm(12602):DexOpt:睡在羊群上(/data/dalvik-cache/system@[电子邮件受保护]@classes.dex) 02-23 11:59:23.419:调试/dalvikvm(12598):DexOpt:睡在羊群上(/data/dalvik-cache/system@[电子邮件受保护]@classes.dex) 02-23 11:59:23.528:调试/dalvikvm(12608):DexOpt:睡在羊群上(/data/dalvik-cache/system@[电子邮件受保护]@classes.dex) 02-23 11:59:23.577:调试/dalvikvm(12598):DexOpt:睡在羊群上(/data/dalvik-cache/system@[电子邮件受保护]@classes.dex) 02-23 11:59:23.698:调试/dalvikvm(12606):DexOpt:睡在羊群上(/data/dalvik-cache/system@[email protected]@classes.dex)
另一个有趣的事情是,作为一个例子,我有一个dexified jar文件
myjar.jar(大小5031)
每个打开的线程此 dex 文件创建一个文件
myjar.jarX.dex (其中 X 是每个线程的唯一整数)(大小 4152)
未完成 DexFile.loadDex 调用的线程仍设法创建 myjar.jarX.dex 文件,但该文件的大小为 3496
我相信 Dalvik 本机代码深处存在某种形式的竞争条件。这对我们来说是一个很大的亮点。有什么建议如何最好地进行吗?
Any android experts could shed some light why this method could hang?
When I pause the thread and look at the stack:
Thread [<13> Thread-15] (Suspended)
DexFile.openDexFile(String, String, int) line: not available [native method]
DexFile.<init>(String, String, int) line: 105
DexFile.loadDex(String, String, int) line: 144
Method.invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not available [native method]
Method.invoke(Object, Object...) line: 521
...you can see it is hanging in the native method DexFile.openDexFile, it never returns.
This is causing serious problems for an application we are writing. It happens randomly and so suggests a race condition of some sort between several threads but I connect detect and deadlocks and plus I would expect the native method to return me something, even an exception would be nice!!
Thanks in advance
I am using Android 2.2 Nexus One Device, I am deploying the application from eclipse to the device. To be sure I totally uninstall the application and re-power the device and I still see the above problem randomly.
UPDATE: I retried on an Android 2.3.3 emulator (API 10) and have the same problem. I am now convinced there is a major bug here. I have created a simple test case to show the problem. Basically I add a single dexified jar to the assets folder of an android project. On startup I copy this file to the application data area. I then kick off x threads and within each thread load this dexified jar file using DexFile.loadDex but giving a different output file name for the generated optimized dex file. If you pick x to be say 30 threads you are almost guaranteed to see several threads hang.
Just to be sure I repeated the test where each thread is given it's own unique dexified jar file. Same problem occurs.
The only LogCat output I see that may give a hint to what is going wrong:
02-23 11:59:23.097: DEBUG/dalvikvm(12598): DexOpt: sleeping on flock(/data/dalvik-cache/system@[email protected]@classes.dex)
02-23 11:59:23.138: DEBUG/dalvikvm(12602): DexOpt: sleeping on flock(/data/dalvik-cache/system@[email protected]@classes.dex)
02-23 11:59:23.357: DEBUG/dalvikvm(12602): DexOpt: sleeping on flock(/data/dalvik-cache/system@[email protected]@classes.dex)
02-23 11:59:23.419: DEBUG/dalvikvm(12598): DexOpt: sleeping on flock(/data/dalvik-cache/system@[email protected]@classes.dex)
02-23 11:59:23.528: DEBUG/dalvikvm(12608): DexOpt: sleeping on flock(/data/dalvik-cache/system@[email protected]@classes.dex)
02-23 11:59:23.577: DEBUG/dalvikvm(12598): DexOpt: sleeping on flock(/data/dalvik-cache/system@[email protected]@classes.dex)
02-23 11:59:23.698: DEBUG/dalvikvm(12606): DexOpt: sleeping on flock(/data/dalvik-cache/system@[email protected]@classes.dex)
The other interesting thing is, as an example I have a dexified jar file
myjar.jar (size 5031)
Each thread that opens this dex file creates a file
myjar.jarX.dex (where X is a unique integer for each thread) (size 4152)
The threads that do not complete the DexFile.loadDex call have still managed to create a myjar.jarX.dex file but the file is of size 3496
I believe there is some form a race condition deep down in the Dalvik native code. This is a big showstopper for us. Any suggestions how best to proceed?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论