Number of methods greater after decompiling/recompiling using version 2.0.3

[GoogleCodeExporter]

What seems to be the problem?
There is an APK that I am able to decompile, inject some code, and recompile 
without any problem with smali/baksmali version 1.3.3.
However, when I try to do the same thing with smali/baksmali version 2.0.3, I 
get an UNEXPECTED TOP-LEVEL EXCEPTION that indicates I have too many methods. 
Does smali/baksmali version 2.0.3 work differently than 1.3.3 that can 
potentially add more methods to the APK?

What is the exact smali/baksmali command that you ran?
java -jar baksmali-2.0.3 <myApk>
java -jar smali-2.0.3 <myApk>

What version of smali/baksmali are you using? What rom are you working
from?
Version 2.0.3 was the one giving me problems

What is the airspeed velocity of an unladen swallow?

Please provide any additional information below: error messages, symptoms,
etc.

Original issue reported on code.google.com by dongjuna...@gmail.com on 31 Mar 2014 at 8:04

[GoogleCodeExporter]

stack trace?

Original comment by jesusfreke@jesusfreke.com on 31 Mar 2014 at 8:20

• Changed state: Pending

[GoogleCodeExporter]

    [junit] UNEXPECTED TOP-LEVEL EXCEPTION:
    [junit] org.jf.util.ExceptionWithContext: Unsigned short value out of range: 65554
    [junit]     at org.jf.dexlib2.writer.DexDataWriter.writeUshort(DexDataWriter.java:116)
    [junit]     at org.jf.dexlib2.writer.InstructionWriter.write(InstructionWriter.java:312)
    [junit]     at org.jf.dexlib2.writer.DexWriter.writeCodeItem(DexWriter.java:980)
    [junit]     at org.jf.dexlib2.writer.DexWriter.writeDebugAndCodeItems(DexWriter.java:759)
    [junit]     at org.jf.dexlib2.writer.DexWriter.writeTo(DexWriter.java:214)
    [junit]     at org.jf.dexlib2.writer.DexWriter.writeTo(DexWriter.java:192)
    [junit]     at org.jf.smali.main.main(main.java:227)

Original comment by dongjuna...@gmail.com on 31 Mar 2014 at 8:25

[GoogleCodeExporter]

Hmm, yeah. that does looks like a method index issue. Can you try compiling it 
with your modifications with 1.3.3 and then disassembling it again? Does it 
have any invoke-*/jumbo methods?

I can't think of any reason that the method count should be different between 
the two versions, so the only thing I can think of is that maybe 1.3.3 is 
automatically using the (now-defunct) /jumbo instructions. I can't remember 
offhand how I had that implemented in the v1 code.

Original comment by jesusfreke@jesusfreke.com on 31 Mar 2014 at 8:45

• Changed state: Accepted

[GoogleCodeExporter]

So after decompiling, adding modifications, and recompiling with 1.3.3, I was 
not able to decompile it again with 1.3.3.

I get the following error:
UNEXPECTED TOP-LEVEL EXCEPTION:
org.jf.dexlib.Util.ExceptionWithContext: regCount does not match the number of 
arguments of the method
        at org.jf.dexlib.Util.ExceptionWithContext.withContext(ExceptionWithContext.java:54)
        at org.jf.dexlib.Code.InstructionIterator.IterateInstructions(InstructionIterator.java:91)
        at org.jf.dexlib.CodeItem.readItem(CodeItem.java:154)
        at org.jf.dexlib.Item.readFrom(Item.java:77)
        at org.jf.dexlib.OffsettedSection.readItems(OffsettedSection.java:48)
        at org.jf.dexlib.Section.readFrom(Section.java:143)
        at org.jf.dexlib.DexFile.<init>(DexFile.java:431)
        at org.jf.baksmali.main.main(main.java:278)
Caused by: java.lang.RuntimeException: regCount does not match the number of 
arguments of the method
        at org.jf.dexlib.Code.Format.Instruction35c.checkItem(Instruction35c.java:161)
        at org.jf.dexlib.Code.Format.Instruction35c.<init>(Instruction35c.java:93)
        at org.jf.dexlib.Code.Format.Instruction35c$Factory.makeInstruction(Instruction35c.java:168)
        at org.jf.dexlib.Code.InstructionIterator.IterateInstructions(InstructionIterator.java:82)
        ... 6 more
Error occured at code address 24
code_item @0x1de924

i did not have any invoke-*/jumbo methods. Only thing with "jumbo" in the code 
was const-string/jumbo

Original comment by dongjuna...@gmail.com on 31 Mar 2014 at 11:52

[GoogleCodeExporter]

Ah, ok. This actually sounds like it was a bug in the earlier smali then. It 
probably truncated the method ids > 64k, essentially wrapping back around to 0. 
With the new smali, it correctly detects the problem and bails.

There's not much I can do here. The only thing I can think of would be to add 
an option similar to dx's to generates multiple dex files if needed. But you 
could get the same effect by splitting the .smali files into 2 separate dirs 
and assembling each separately.

Original comment by jesusfreke@jesusfreke.com on 31 Mar 2014 at 11:57

• Changed state: Done

[GoogleCodeExporter]

I see... But are you certain that it truncated the method ids > 64k? I have 
also gotten error in the previously version of smali about having too many 
methods.

The error message in the previous version looked like this:
org.jf.dexlib.Util.ExceptionWithContext: method index is too large. 67025

If it truncated the method ids > 64k, wouldn't it not be able to get this error?
Thank you so much for your help by the way.

Original comment by dongjuna...@gmail.com on 1 Apr 2014 at 12:08

[GoogleCodeExporter]

Any updates on my comment above?

Original comment by dongjuna...@gmail.com on 14 Apr 2014 at 11:17

[GoogleCodeExporter]

I'm not sure what the issue was in the previous version. As far as I can tell, 
it's working correctly in the current version.

Original comment by jesusfreke@jesusfreke.com on 14 Apr 2014 at 11:22