title: DexFile.loadDex hangs
body: <p>Any android experts could shed some light why this method could hang?</p>
  
  <p>When I pause the thread and look at the stack:</p>
  
  <pre><code>Thread [&lt;13&gt; Thread-15] (Suspended) 
  DexFile.openDexFile(String, String, int) line: not available [native method]    
  DexFile.&lt;init&gt;(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  
  </code></pre>
  
  <p>...you can see it is hanging in the native method DexFile.openDexFile, it never returns.</p>
  
  <p>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!!</p>
  
  <p>Thanks in advance</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Just to be sure I repeated the test where each thread is given it's own unique dexified jar file. Same problem occurs.</p>
  
  <p>The only LogCat output I see that may give a hint to what is going wrong:</p>
  
  <p>02-23 11:59:23.097: DEBUG/dalvikvm(12598): DexOpt: sleeping on flock(/data/dalvik-cache/system@framework@core.jar@classes.dex)
  02-23 11:59:23.138: DEBUG/dalvikvm(12602): DexOpt: sleeping on flock(/data/dalvik-cache/system@framework@core.jar@classes.dex)
  02-23 11:59:23.357: DEBUG/dalvikvm(12602): DexOpt: sleeping on flock(/data/dalvik-cache/system@framework@framework.jar@classes.dex)
  02-23 11:59:23.419: DEBUG/dalvikvm(12598): DexOpt: sleeping on flock(/data/dalvik-cache/system@framework@framework.jar@classes.dex)
  02-23 11:59:23.528: DEBUG/dalvikvm(12608): DexOpt: sleeping on flock(/data/dalvik-cache/system@framework@core.jar@classes.dex)
  02-23 11:59:23.577: DEBUG/dalvikvm(12598): DexOpt: sleeping on flock(/data/dalvik-cache/system@framework@services.jar@classes.dex)
  02-23 11:59:23.698: DEBUG/dalvikvm(12606): DexOpt: sleeping on flock(/data/dalvik-cache/system@framework@core.jar@classes.dex)</p>
  
  <p>The other interesting thing is, as an example I have a dexified jar file</p>
  
  <p>myjar.jar   (size 5031)</p>
  
  <p>Each thread that opens this dex file creates a file </p>
  
  <p>myjar.jarX.dex (where X is a unique integer for each thread) (size 4152)</p>
  
  <p>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</p>
  
  <p>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?</p>