[android-developers] Re: dex failure
Hi, I have the same problem, can you details how you fixe it ? Thanks you. On 31 mar, 02:46, BeWillDir wmmichael...@gmail.com wrote: Thank you. The dump operation helped me isolate the problem. The class files are indeed identical (confirmed by cmp). The problem was more insidious. The dx command worked OK on the original system, but not on the new one. Here's why: The proximate cause was that I was sloppy installing java. The new (Debian) system has a java command that does this: b...@gizmo:~/android/Apprise$ java Usage: gij [OPTION] ... CLASS [ARGS] ... to invoke CLASS.main, or gij -jar [OPTION] ... JARFILE [ARGS] ... to execute a jar file Try `gij --help' for more information. ...while the original system runs a Sun version. Changing a link in / etc/alternatives fixed the problem. Of course, someone naive like me likes to believe this shouldn't matter - dx should work in either jre. OK, not naive. Idealistic. Thanks again. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: dex failure
Hi, I have the same problem, can you detail how you fix it ? Thanks you. On 30 mar, 22:18, Dan Bornstein danf...@android.com wrote: On Mon, Mar 30, 2009 at 11:12 AM, BeWillDir wmmichael...@gmail.com wrote: Now I'm preparing for a trip and I want to continue development on my netbook, but I'm haviing trouble with the build process. It appears to run the compiler OK, and generates a set of class files identical to that on my first system (verified all checksums), but unlike the first system, the netbook build fails in the dx phase with messages as shown below. [...] dex: [echo] Converting compiled files and external libraries into bin/classes.dex... [apply] [apply] trouble processing: [apply] invalid constant pool index [apply] ...while parsing attributes[1] [apply] ...while parsing Code attribute at offset 0715 [apply] ...while parsing attributes[0] [apply] ...while parsing methods[0] [apply] ...while parsing net/from/apprise/Apprise.class [apply] ...while processing net/from/apprise/Apprise.class The message invalid constant pool index is a smoking gun. In classfiles constant pool index 0 is *always* invalid, so, though you say that the classfiles are identical, this is evidence that, at least by the time dx gets to run, they are not. You might try to diagnose this further by comparing the class Apprise.class from a known-good run (from the old machine) with the version of the file that dx complained about. You can try good old cmp (binary compare), and you might also want to do an annotated dump of the two files. dx --dump Name.class can do the latter. -dan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: dex failure
Oh, hey, no problem. Sometimes it's not a matter of getting the right fix from someone, but rather, a sympathetic and intelligent correspondent. I work alone and that's, uh, lonely. And I can't blame you for wanting to double-check my assumptions. I would do the same. I'll try to get you more useful info on that failure mode, but unfortunately, this development environment is still rather opaque to me, so I'll be stumbling along... so standby. On Mar 30, 8:58 pm, Dan Bornstein danf...@android.com wrote: On Mon, Mar 30, 2009 at 5:46 PM, BeWillDir wmmichael...@gmail.com wrote: The dx command worked OK on the original system, but not on the new one. Here's why: The proximate cause was that I was sloppy installing java. The new (Debian) system has a java command that does this: b...@gizmo:~/android/Apprise$ java Usage: gij [OPTION] ... CLASS [ARGS] ... to invoke CLASS.main, or gij -jar [OPTION] ... JARFILE [ARGS] ... to execute a jar file Try `gij --help' for more information. ...while the original system runs a Sun version. Changing a link in / etc/alternatives fixed the problem. Of course, someone naive like me likes to believe this shouldn't matter - dx should work in either jre. OK, not naive. Idealistic. Agreed, and since dx isn't doing anything particularly fancy, this perhaps indicative of a bug in gij. We've seen bugs in JREs creep up before, and there is even a bit of code in dx that detects one of the known failure modes, but yours is a new one (at least for me). I'd love to be able to detect it, so if you are so inclined, please try tracking down what the most immediate failure is. (That is, by the time it turns into a bogus constant pool index, it's probably too late, as that could have been a legitimate complaint.) If you can figure that out, then we can probably add another bit of detection code and maybe save some folks a little time down the line. Thanks for following up, and my apologies that I steered you in the wrong direction to begin with. -dan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: dex failure
Cartouche - for my system, it was simply a matter of changing a symbolic link so that the Sun runtime environment is use when the java command is invoked from a shell. On the Debian system I'm using, that link is in /etc/alternatives. And in my case I did this: cd /etc/alternatives ln -s -f /usr/lib/jvm/java-6-sun/jre/bin/java On Mar 31, 10:33 am, Cartouche hafid.s...@gmail.com wrote: Hi, I have the same problem, can you detail how you fix it ? Thanks you. On 30 mar, 22:18, Dan Bornstein danf...@android.com wrote: On Mon, Mar 30, 2009 at 11:12 AM, BeWillDir wmmichael...@gmail.com wrote: Now I'm preparing for a trip and I want to continue development on my netbook, but I'm haviing trouble with the build process. It appears to run the compiler OK, and generates a set of class files identical to that on my first system (verified all checksums), but unlike the first system, the netbook build fails in the dx phase with messages as shown below. [...] dex: [echo] Converting compiled files and external libraries into bin/classes.dex... [apply] [apply] trouble processing: [apply] invalid constant pool index [apply] ...while parsing attributes[1] [apply] ...while parsing Code attribute at offset 0715 [apply] ...while parsing attributes[0] [apply] ...while parsing methods[0] [apply] ...while parsing net/from/apprise/Apprise.class [apply] ...while processing net/from/apprise/Apprise.class The message invalid constant pool index is a smoking gun. In classfiles constant pool index 0 is *always* invalid, so, though you say that the classfiles are identical, this is evidence that, at least by the time dx gets to run, they are not. You might try to diagnose this further by comparing the class Apprise.class from a known-good run (from the old machine) with the version of the file that dx complained about. You can try good old cmp (binary compare), and you might also want to do an annotated dump of the two files. dx --dump Name.class can do the latter. -dan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: dex failure
Oh, and here is the result with the Sun JRE for comparison...
b...@gizmo:~/android/Apprise$ dx --dump bin/classes/net/from/apprise/
Apprise.class
reading bin/classes/net/from/apprise/Apprise.class...
begin classfile
magic: cafebabe
minor_version:
major_version: 0031
constant_pool_count: 007b
constant_pool:
0001: method{android.app.Activity.init:()V}
0002: string{6095326873}
0003: field{net.from.apprise.Apprise.tDest:Ljava/lang/String;}
0004: string{SMS_SENT}
0005: field{net.from.apprise.Apprise.SENT:Ljava/lang/String;}
0006: method{android.app.Activity.onCreate:(Landroid/os/Bundle;)V}
0007: string{Apprise}
0008: string{Here}
...stuff omitted again...
0076: utf8{sleep}
0077: utf8{(J)V}
0078: utf8{unregisterReceiver}
0079: utf8{(Landroid/content/BroadcastReceiver;)V}
007a: utf8{(Ljava/lang/String;Ljava/lang/String;Ljava/lang/
Throwable;)I}
end constant_pool
access_flags: public|super
this_class: type{net.from.apprise.Apprise}
super_class: type{android.app.Activity}
interfaces_count:
fields_count: 0003
fields[0]:
access_flags: private|static|final
name: TAG
descriptor: Ljava/lang/String;
attributes_count: 0001
attributes[0]:
name: ConstantValue
length: 0002
value: string{Apprise}
end attributes[0]
end fields[0]
fields[1]:
access_flags:
name: tDest
descriptor: Ljava/lang/String;
attributes_count:
end fields[1]
fields[2]:
access_flags:
name: SENT
descriptor: Ljava/lang/String;
attributes_count:
end fields[2]
methods_count: 0002
methods[0]:
access_flags: public
name: init
descriptor: ()V
attributes_count: 0001
attributes[0]:
name: Code
length: 0047
max_stack: 0002
max_locals: 0001
code_length: 0011
: aload_0 // 00
0001: invokespecial method{android.app.Activity.init:()V}
0004: aload_0 // 00
0005: ldc string{6095326873}
0007: putfield field{net.from.apprise.Apprise.tDest:Ljava/lang/
String;}
000a: aload_0 // 00
000b: ldc string{SMS_SENT}
000d: putfield field{net.from.apprise.Apprise.SENT:Ljava/lang/
String;}
0010: return
exception_table_length:
attributes_count: 0002
attributes[0]:
name: LineNumberTable
length: 0012
line_number_table_length: 0004
14
0004 18
000a 19
0010 49
end attributes[0]
attributes[1]:
name: LocalVariableTable
length: 000c
local_variable_table_length: 0001
..0011 this Lnet/from/apprise/Apprise;
end attributes[1]
end attributes[0]
end methods[0]
methods[1]:
access_flags: public
name: onCreate
descriptor: (Landroid/os/Bundle;)V
attributes_count: 0001
attributes[0]:
name: Code
length: 0136
max_stack: 0006
max_locals: 0008
code_length: 0082
: aload_0 // 00
0001: aload_1 // 01
0002: invokespecial method{android.app.Activity.onCreate:(Landroid/
os/Bundl
e;)V}
0005: ldc string{Apprise}
0007: ldc string{Here}
0009: invokestatic method{android.util.Log.d:(Ljava/lang/
String;Ljava/lang/
String;)I}
000c: pop
000d: aload_0 // 00
000e: ldc #+7f02
0010: invokevirtual method{net.from.apprise.Apprise.setContentView:
(I)V}
0013: invokestatic method
{android.telephony.gsm.SmsManager.getDefault:()Lan
droid/telephony/gsm/SmsManager;}
0016: astore_2 // 02
0017: aconst_null
0018: astore_3 // 03
0019: aload_0 // 00
001a: iconst_0 // #+00
001b: new type{android.content.Intent}
001e: dup
001f: ldc string{net.from.Apprise.IGNORE_ME}
0021: invokespecial method{android.content.Intent.init:(Ljava/
lang/String
;)V}
0024: iconst_0 // #+00
0025: invokestatic method{android.app.PendingIntent.getBroadcast:
(Landroid/
content/Context;ILandroid/content/Intent;I)Landroid/app/
PendingIntent;}
0028: astore 04
002a: aload_0 // 00
002b: iconst_0 // #+00
002c: new type{android.content.Intent}
002f: dup
0030: ldc string{net.from.Apprise.SMS_SENT}
0032: invokespecial method{android.content.Intent.init:(Ljava/
lang/String
;)V}
0035: iconst_0 // #+00
0036: invokestatic method{android.app.PendingIntent.getBroadcast:
(Landroid/
content/Context;ILandroid/content/Intent;I)Landroid/app/
PendingIntent;}
0039: astore 05
003b: new type{net.from.apprise.Apprise$APBR}
003e: dup
003f: aload_0 // 00
0040: invokespecial method{net.from.apprise.Apprise$APBR.init:
(Lnet/from/
apprise/Apprise;)V}
0043: astore 06
0045: aload_0 // 00
0046: aload 06
0048: new type{android.content.IntentFilter}
004b: dup
004c: aload_0 // 00
004d: getfield field{net.from.apprise.Apprise.SENT:Ljava/lang/
String;}
0050: invokespecial method{android.content.IntentFilter.init:
(Ljava/lang/
String;)V}
0053: invokevirtual method
{net.from.apprise.Apprise.registerReceiver:(Landr
[android-developers] Re: dex failure
OK, Dan, here are fragments of the output resulting from 'dx --dump
bin/classes/net/from/apprise/Apprise.class' when gij is used. Results
are similar for any class file. Unfortunately, it's not an outright
crash with a stack dump and I suppose this only gives you an
approximate idea of where it runs off the rails at best. So if there
is a switch or incantation that will yield something more useful, say
the word and I'll do that...
b...@gizmo:~/android/Apprise$ dx --dump bin/classes/net/from/apprise/
Apprise.class
reading bin/classes/net/from/apprise/Apprise.class...
begin classfile
magic: cafebabe
minor_version:
major_version: 0031
constant_pool_count: 007b
constant_pool:
0001: method{android.app.Activity.init:()V}
0002: string{6095326873}
0003: field{net.from.apprise.Apprise.tDest:Ljava/lang/String;}
0004: string{SMS_SENT}
0005: field{net.from.apprise.Apprise.SENT:Ljava/lang/String;}
0006: method{android.app.Activity.onCreate:(Landroid/os/Bundle;)V}
0007: string{Apprise}
0008: string{Here}
...stuff omitted from post...
0075: utf8{java/lang/Thread}
0076: utf8{sleep}
0077: utf8{(J)V}
0078: utf8{unregisterReceiver}
0079: utf8{(Landroid/content/BroadcastReceiver;)V}
007a: utf8{(Ljava/lang/String;Ljava/lang/String;Ljava/lang/
Throwable;)I}
end constant_pool
access_flags: public|super
this_class: type{net.from.apprise.Apprise}
super_class: type{android.app.Activity}
interfaces_count:
fields_count: 0003
fields[0]:
access_flags: private|static|final
name: TAG
descriptor: Ljava/lang/String;
attributes_count: 0001
attributes[0]:
name: ConstantValue
length: 0002
value: string{Apprise}
end attributes[0]
end fields[0]
fields[1]:
access_flags:
name: tDest
descriptor: Ljava/lang/String;
attributes_count:
end fields[1]
fields[2]:
access_flags:
name: SENT
descriptor: Ljava/lang/String;
attributes_count:
end fields[2]
methods_count: 0002
methods[0]:
access_flags: public
name: init
descriptor: ()V
attributes_count: 0001
attributes[0]:
name: Code
length: 0047
max_stack: 0002
max_locals: 0001
code_length: 0011
: aload_0 // 00
0001: invokespecial method{android.app.Activity.init:()V}
0004: aload_0 // 00
0005: ldc string{6095326873}
0007: putfield field{net.from.apprise.Apprise.tDest:Ljava/lang/
String;}
000a: aload_0 // 00
000b: ldc string{SMS_SENT}
000d: putfield field{net.from.apprise.Apprise.SENT:Ljava/lang/
String;}
0010: return
exception_table_length:
attributes_count: 0002
attributes[0]:
name: LineNumberTable
length: 0012
line_number_table_length: 0004
14
0004 18
000a 19
0010 49
end attributes[0]
attributes[1]:
name: LocalVariableTable
length: 000c
local_variable_table_length: 0001
trouble parsing:
invalid constant pool index
...while parsing attributes[1]
...while parsing Code attribute at offset 072f
...while parsing attributes[0]
...while parsing methods[0]
...while parsing bin/classes/net/from/apprise/Apprise.class
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: dex failure
On Mon, Mar 30, 2009 at 11:12 AM, BeWillDir wmmichael...@gmail.com wrote: Now I'm preparing for a trip and I want to continue development on my netbook, but I'm haviing trouble with the build process. It appears to run the compiler OK, and generates a set of class files identical to that on my first system (verified all checksums), but unlike the first system, the netbook build fails in the dx phase with messages as shown below. [...] dex: [echo] Converting compiled files and external libraries into bin/classes.dex... [apply] [apply] trouble processing: [apply] invalid constant pool index [apply] ...while parsing attributes[1] [apply] ...while parsing Code attribute at offset 0715 [apply] ...while parsing attributes[0] [apply] ...while parsing methods[0] [apply] ...while parsing net/from/apprise/Apprise.class [apply] ...while processing net/from/apprise/Apprise.class The message invalid constant pool index is a smoking gun. In classfiles constant pool index 0 is *always* invalid, so, though you say that the classfiles are identical, this is evidence that, at least by the time dx gets to run, they are not. You might try to diagnose this further by comparing the class Apprise.class from a known-good run (from the old machine) with the version of the file that dx complained about. You can try good old cmp (binary compare), and you might also want to do an annotated dump of the two files. dx --dump Name.class can do the latter. -dan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: dex failure
Thank you. The dump operation helped me isolate the problem. The class files are indeed identical (confirmed by cmp). The problem was more insidious. The dx command worked OK on the original system, but not on the new one. Here's why: The proximate cause was that I was sloppy installing java. The new (Debian) system has a java command that does this: b...@gizmo:~/android/Apprise$ java Usage: gij [OPTION] ... CLASS [ARGS] ... to invoke CLASS.main, or gij -jar [OPTION] ... JARFILE [ARGS] ... to execute a jar file Try `gij --help' for more information. ...while the original system runs a Sun version. Changing a link in / etc/alternatives fixed the problem. Of course, someone naive like me likes to believe this shouldn't matter - dx should work in either jre. OK, not naive. Idealistic. Thanks again. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: dex failure
On Mon, Mar 30, 2009 at 5:46 PM, BeWillDir wmmichael...@gmail.com wrote: The dx command worked OK on the original system, but not on the new one. Here's why: The proximate cause was that I was sloppy installing java. The new (Debian) system has a java command that does this: b...@gizmo:~/android/Apprise$ java Usage: gij [OPTION] ... CLASS [ARGS] ... to invoke CLASS.main, or gij -jar [OPTION] ... JARFILE [ARGS] ... to execute a jar file Try `gij --help' for more information. ...while the original system runs a Sun version. Changing a link in / etc/alternatives fixed the problem. Of course, someone naive like me likes to believe this shouldn't matter - dx should work in either jre. OK, not naive. Idealistic. Agreed, and since dx isn't doing anything particularly fancy, this perhaps indicative of a bug in gij. We've seen bugs in JREs creep up before, and there is even a bit of code in dx that detects one of the known failure modes, but yours is a new one (at least for me). I'd love to be able to detect it, so if you are so inclined, please try tracking down what the most immediate failure is. (That is, by the time it turns into a bogus constant pool index, it's probably too late, as that could have been a legitimate complaint.) If you can figure that out, then we can probably add another bit of detection code and maybe save some folks a little time down the line. Thanks for following up, and my apologies that I steered you in the wrong direction to begin with. -dan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
