#29 ClassCastException: java.lang.Object

[David Sitsky]

I am using 1.6.2, and despite the previous bug report
with the "Error: java.lang.Object" being fixed, I am still
getting this error.

I've attached the trace of the run (with -verbose) and
the sensitive classnames removed.

Everything works fine if I specify -dontobfuscate.

[David Sitsky]

Proguard run with -verbose

[David Sitsky]

Logged In: YES
user_id=208928

I'll provide more information soon. It seems to happen only
with a specific -keep option in my config. Stay tuned...

[David Sitsky]

Logged In: YES
user_id=208928

As mentioned, there is one specific class in my application,
where I have a -keep in the form:

-keep public class com.somename.SomeClass {
public <init>(com.somename.AnotherClass);
}

When I comment out this -keep (I have a bunch of others),
the obfuscator completes. Note I have another -keep for
SomeClass2, which is exactly the same as the one above.

I am happy to make any experimental code changes to get
this fixed... just let me know what you like me to do.

This occurs with 1.4.1 and 1.4.1_03 under Linux and Windows.

[Eric Lafortune]

Logged In: YES
user_id=555208

That's very useful info, thanks. You're the third person to
report this bug, which has been elusive to me so far. I'd
like to fix it for the impending release 1.7.

One thought: could you try keeping
"com.somename.AnotherClass"? Maybe it isn't used elsewhere,
causing confusion in ProGuard about whether it should be
kept or not.

If you can spend some more time, you could add the debug
code I've suggested in this message:

https://sourceforge.net/forum/message.php?msg_id=2110466

The last lines before the exception occurs should contain
some useful information. Especially the class hierarchies of
the mentioned classes could be useful.

As a workaround, you can catch the exception and return null.

Thanks again,

Eric.

[David Sitsky]

Logged In: YES
user_id=208928

I'll send you the relevant output from the debug messages via
an email to you. I may be on th road this week, so I might
not be able to give you any prompt replies.

[Eric Lafortune]

Logged In: YES
user_id=555208

With the combined help of some ProGuard users, I've been able
to reproduce and fix this bug. The problem occurred on input
code like this:

interface SomeInterface { m(); }

abstract class SomeAbstractClass implements
SomeInterface { }

class SomeConcreteClass extends SomeAbstractClass { m()
{...} }

If the code calls "someAbstractClass.m();", and if it never
mentions SomeInterface, and if it is compiled with "-target
1.2" (the default in JDK1.4), the processing went wrong.
ProGuard erroneously considered the interface as not being
used in the shrinking step, but then it tried to use it
anyway in the obfuscation step. Note that the input code is
slightly unusual (it seems cleaner to call the interface, not
the abstract class), but it is valid.

Fix: in proguard/shrink/UsageMarker.java, on line 454, replace:

// When compiled with "-target 1.2", the class actually
// containing the referenced method may be higher up the
// hierarchy. Being a superclass, it will be marked
// automatically.
by:
// When compiled with "-target 1.2", the class or interface
// actually containing the referenced method may be
higher up
// the hierarchy. Make sure it's marked, in case it isn't
// used elsewhere.
methodrefCpInfo.referencedClassAccept(this);

This fix is included in version 1.7, which I will release
very soon now.

Eric.