Issue222819

Consider the following script --

==========
#!/usr/bin/env jpython

from java.util import Date

class SubDate(Date):
    def toString(self): return 'SubDate.toString() -> ' + Date.toString(self)

class SubSubDate(SubDate):
    def toString(self): return 'SubSubDate.toString() -> ' +
SubDate.toString(self)

print Date().toString()
print SubDate().toString()
print SubSubDate().toString()
==========

The output is as follows --

==========
Fri Oct 22 12:53:58 CDT 1999
SubDate.toString() -> Fri Oct 22 12:53:58 CDT 1999
Traceback (innermost last):
  File "test.py", line 12, in ?
  File "test.py", line 8, in toString
  File "test.py", line 6, in toString
java.lang.StackOverflowError
        at org.python.core.PyClass.lookupGivingClass(PyClass.java:137)
        at org.python.core.PyJavaClass.lookupGivingClass(PyJavaClass.java:673)
        at org.python.core.PyClass.lookup(PyClass.java:155)
        at org.python.util.PythonInterpreter.execfile(PythonInterpreter.java:132)
        < ... >
        at org.python.proxies.SubDate$0.toString(Unknown Source)
        at org.python.proxies.SubSubDate$1.super__toString(Unknown Source)
        at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:156)
        < ... >
        at org.python.proxies.SubDate$0.toString(Unknown Source)
        at org.python.proxies.SubSubDate$1.super__toString(Unknown Source)
        at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:156)
        < ... > 
        at org.python.util.jpython.main(jpython.java:123)
==========

What seems to happen is that SubSubDate.toString() calls SubDate.toString()
calls Date.toString() ... which then turns around and calls the derived-most
implementation of toString() all over again, ie, the one at SubSubDate. This
goes on and on until the above stack overflow occurs.

Note that with only one level of inheritance, ie, calling SubDate.toString(),
it worked correctly with no problems.

I originally observed this problem with overriding
java.lang.Thread.interrupt(),
so the above simplified test case has been reproduced elsewhere.

I can reproduce this with Sun Solaris JDK versions 1.3, 1.2.2 and 1.1.8.

Just checked that the nasty bug is still there.
It should be solved for sure, at least the 
stack overflow.
Not analyzed yet.

Any python subclass that contains a java class as a parent 
will have a proxy created for it. Also, in the PyReflectionFunction __call__
there is code to "translate" unbound methods to bound "super__" methods.
However the "self" argument passed to this method is null so that
the superclass (Here SubDate) again looks for a "super__" method ( viz:
super__super__toString()!) This of course fails and so the
call drops through.

I can't really make heads or tails of this code so I have no idea where the "bug"
is (altough the search for "super__super__" is surely wrong).  I also think the fact
that the SubSubDate class has a java proxyClass created for it (--because SubDate 
has a proxyClass--- see PyClass.init()) somehow contributes to the recursion.

Ian Castleden's fix added to the interpreter. Same fix must also be added to jythonc. The bug report will closed when that is done.

Logged In: YES 
user_id=4201

Fixed in:
PyClass.java: 2.23;
ProxyMaker.java: 2.12;
JavaMaker.java: 2.10;
ObjectFactory.py: 2.7;
compile.py: 2.17;
proxies.py: 2.10;

Logged In: YES 
user_id=4201

Reverted the fix and reopened the bug. The reason for is 
the situation described here:
http://www.geocrawler.com/lists/3/SourceForge/7018/0/5685848
/

Logged In: YES 
user_id=61408

fixed (both in interp and jythonc) .

Note: the code affected and related to this needs a big
revision.