dex fails placing debug info

by Michael Newton » Tue, 20 Apr 2010 13:08:24 GMT


Sponsored Links
  hope someone can offer some insight on this problem. My build was
failing with a dex error. After I turned verbosity up to debug I got
the following:

Buildfile: build.xml
[setup] Project Target: Android 1.6
[setup] API level: 4
[setup] WARNING: No minSdkVersion value set. Application will
install on all Android versions.

(snip)

-dex:
[echo] Converting compiled files and external libraries into /
Users/newton/scratch/bin/classes.dex...
[echo]
[apply]
[apply] trouble writing output:
[apply] com.android.dx.util.ExceptionWithContext: shouldn't happen
[apply] at
com.android.dx.util.ExceptionWithContext.withContext(ExceptionWithContext.java:
46)
[apply] at
com.android.dx.dex.file.DebugInfoItem.place0(DebugInfoItem.java:79)
[apply] at
com.android.dx.dex.file.OffsettedItem.place(OffsettedItem.java:241)
[apply] at
com.android.dx.dex.file.MixedItemSection.placeItems(MixedItemSection.java:
312)
[apply] at com.android.dx.dex.file.DexFile.toDex0(DexFile.java:
525)
[apply] at com.android.dx.dex.file.DexFile.toDex(DexFile.java:
196)
[apply] at com.android.dx.command.dexer.Main.writeDex(Main.java:
406)
[apply] at com.android.dx.command.dexer.Main.run(Main.java:143)
[apply] at com.android.dx.command.dexer.Main.main(Main.java:120)
[apply] at com.android.dx.command.Main.main(Main.java:87)
[apply] Caused by: java.lang.RuntimeException: shouldn't happen
[apply] at
com.android.dx.dex.file.DebugInfoEncoder.emitLocalsAtAddress(DebugInfoEncoder.java:
314)
[apply] at
com.android.dx.dex.file.DebugInfoEncoder.convert0(DebugInfoEncoder.java:
220)
[apply] at
com.android.dx.dex.file.DebugInfoEncoder.convert(DebugInfoEncoder.java:
155)
[apply] at
com.android.dx.dex.file.DebugInfoItem.encode0(DebugInfoItem.java:188)
[apply] at
com.android.dx.dex.file.DebugInfoItem.encode(DebugInfoItem.java:144)
[apply] at
com.android.dx.dex.file.DebugInfoItem.place0(DebugInfoItem.java:76)
[apply] ... 8 more
[apply] ...while placing debug info for
com.sshtools.j2ssh.transport.publickey.SshPublicKey.getFingerprint:
()Ljava/lang/String;
[apply] ...while placing
com.android.dx.dex.file.debuginfoi...@55bbe9aa
[apply] ...while writing section 10
[apply]


Here is the source of the class where it is failing to place debug
info:
package com.sshtools.j2ssh.transport.publickey;

import com.sshtools.j2ssh.util.Hash;
import java.security.NoSuchAlgorithmException;

public abstract class SshPublicKey {

public abstract String getAlgorithmName();

public abstract int getBitLength();

public abstract byte[] getEncoded();

public String getFingerprint() {
try {
Hash md5 = new Hash("MD5");
md5.putBytes(getEncoded());

byte[] digest = md5.doFinal();
int bits = getBitLength();
bits = (((bits % 8) != 0) ? (bits += (bits % 8)) : bits);

String ret = String.valueOf(bits);

for (int i = 0; i < digest.length; i++) {
ret += (((i == 0) ? ":" : "") + " " +
Integer.toHexString(digest[i] & 0xFF));
}

return ret;
} catch (NoSuchAlgorithmException nsae) {
return null;
}
}

publ



dex fails placing debug info

by Dan Bornstein » Wed, 21 Apr 2010 07:33:11 GMT


 On Mon, Apr 19, 2010 at 4:26 PM, Michael Newton



This looks like a bug in dx (the tool that turns .class files into
.dex files). Since compilers can produce different output for the same
source, it's much more interesting to see the compiled .class file
that is being processed.

Please file a bug by following the directions at
< http://source.android.com/report-bugs> ;. Again, in this case,
attaching the .class file that fails is much better than just
including the source text.

As a workaround, you might try compiling without debugging info (that
is, removing "-g" from your javac command line). You might also try
splitting the failing method (getFingerPrint) in various places (e.g.,
put the try body in a separate method), as that will change the
emitted code and has a good chance of avoiding the problem.

Cheers,

-dan

--


Sponsored Links


dex fails placing debug info

by Michael Newton » Wed, 21 Apr 2010 23:26:17 GMT


 I fixed this - this code is where the problem is:

            int bits = getBitLength();
            bits = (((bits % 8) != 0) ? (bits += (bits % 8)) : bits);

When I assigned the result of the expression in the second line to a
new variable instead of back to int bits, the problem went away.

The clue was in  http://code.google.com/p/android/issues/detail?id=2868 
- may be the same kind of issue.

M.




>



dex fails placing debug info

by fadden » Fri, 23 Apr 2010 04:10:41 GMT


 



Can you attach the failing and non-failing .class files to that bug?

--



Other Threads

1. Garbage collector using huge amount of cpu time?

While our application is basically doing nothing the garbage collector
is very busy:

INFO/dalvikvm-heap(515): GC! (7789ms since last GC)
INFO/dalvikvm-heap(515): GC old usage 58.3%; now 2.800MB used /
4.800MB soft max (5.252MB real max)
INFO/dalvikvm-heap(515): GC freed 14928 objects / 2095000 bytes in
231ms
INFO/dalvikvm-heap(515): GC! (7509ms since last GC)
INFO/dalvikvm-heap(515): GC old usage 58.1%; now 2.790MB used /
4.790MB soft max (5.252MB real max)
INFO/dalvikvm-heap(515): GC freed 14883 objects / 2100932 bytes in
193ms
INFO/dalvikvm-heap(515): GC! (7496ms since last GC)
INFO/dalvikvm-heap(515): GC old usage 58.4%; now 2.799MB used /
4.799MB soft max (5.252MB real max)
INFO/dalvikvm-heap(515): GC freed 14741 objects / 2086380 bytes in
236ms
INFO/dalvikvm-heap(515): GC! (7887ms since last GC)
INFO/dalvikvm-heap(515): GC old usage 58.3%; now 2.799MB used /
4.799MB soft max (5.252MB real max)
INFO/dalvikvm-heap(515): GC freed 14899 objects / 2093612 bytes in
199ms
INFO/dalvikvm-heap(515): GC! (7444ms since last GC)
INFO/dalvikvm-heap(515): GC old usage 58.3%; now 2.799MB used /
4.799MB soft max (5.252MB real max)
INFO/dalvikvm-heap(515): GC freed 14784 objects / 2096544 bytes in
204ms

As you can see every few seconds the GC is called and is using a
decent fraction of a second to complete his task. Is this normal
behaviour in the simulator, or is something going wrong?
--~--~---------~--~----~------------~-------~--~----~

2. Nested ViewGroups causing StackOverflowError due to drawing cache?

I am also experiencing this problem in my view hierarchy.  I have a
somewhat complex arrangement of views underneath a TabHost that end up
being maybe 6 - 9 layers deep.  If I remove just a single layer
anywhere in the view hierarchy, the problem disappears.

I am at a loss for a work-around to continue designing my app without
intentionally removing features to reduce the complexity of my view.



> too:

3. XMLInputFactory exception

4. can a web page know if it is being opened on android?

5. How to get some GSM informations

6. Access Java based WebService using Android

7. In toast cancel()