|
From: <no...@so...> - 2000-12-16 20:52:19
|
Bug #122819, was updated on 2000-Nov-18 11:11
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Submitted by: bckfnn
Assigned to : nobody
Summary: Multi-level Java method overriding fails
Details: 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.
Follow-Ups:
Date: 2000-Dec-16 12:52
By: pedronis
Comment:
Just checked that the nasty bug is still there.
It should be solved for sure, at least the
stack overflow.
Not analyzed yet.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=122819&group_id=12867
|
|
From: <no...@so...> - 2001-02-19 09:25:10
|
Bug #122819, was updated on 2000-Nov-18 11:11
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Submitted by: bckfnn
Assigned to : nobody
Summary: Multi-level Java method overriding fails
Details: 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.
Follow-Ups:
Date: 2001-Feb-19 01:26
By: ianzsk
Comment:
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.
-------------------------------------------------------
Date: 2000-Dec-16 12:52
By: pedronis
Comment:
Just checked that the nasty bug is still there.
It should be solved for sure, at least the
stack overflow.
Not analyzed yet.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=122819&group_id=12867
|
|
From: <no...@so...> - 2001-02-23 20:24:24
|
Bug #122819, was updated on 2000-Nov-18 11:11
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Submitted by: bckfnn
Assigned to : nobody
Summary: Multi-level Java method overriding fails
Details: 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.
Follow-Ups:
Date: 2001-Feb-23 12:26
By: bckfnn
Comment:
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.
-------------------------------------------------------
Date: 2001-Feb-19 01:26
By: ianzsk
Comment:
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.
-------------------------------------------------------
Date: 2000-Dec-16 12:52
By: pedronis
Comment:
Just checked that the nasty bug is still there.
It should be solved for sure, at least the
stack overflow.
Not analyzed yet.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=122819&group_id=12867
|
|
From: <no...@so...> - 2001-06-14 12:16:37
|
Bugs item #222819, was updated on 2000-11-18 11:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=222819&group_id=12867 Category: Core Group: None Status: Open Resolution: Fixed Priority: 4 Submitted By: Finn Bock (bckfnn) >Assigned to: Samuele Pedroni (pedronis) Summary: Multi-level Java method overriding fails Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-05-07 12:24 Message: 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 / ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-03-22 12:50 Message: 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; ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-02-23 12:26 Message: 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. ---------------------------------------------------------------------- Comment By: ian west (ianzsk) Date: 2001-02-19 01:26 Message: 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. ---------------------------------------------------------------------- Comment By: Samuele Pedroni (pedronis) Date: 2000-12-16 12:52 Message: Just checked that the nasty bug is still there. It should be solved for sure, at least the stack overflow. Not analyzed yet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=222819&group_id=12867 |
|
From: <no...@so...> - 2001-03-22 20:50:24
|
Bugs item #222819, was updated on 2000-11-18 11:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=222819&group_id=12867 Category: Core Group: None >Status: Closed Priority: 4 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: Multi-level Java method overriding fails Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-03-22 12:50 Message: 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; ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-02-23 12:26 Message: 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. ---------------------------------------------------------------------- Comment By: ian west (ianzsk) Date: 2001-02-19 01:26 Message: 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. ---------------------------------------------------------------------- Comment By: Samuele Pedroni (pedronis) Date: 2000-12-16 12:52 Message: Just checked that the nasty bug is still there. It should be solved for sure, at least the stack overflow. Not analyzed yet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=222819&group_id=12867 |
|
From: <no...@so...> - 2001-05-07 19:24:39
|
Bugs item #222819, was updated on 2000-11-18 11:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=222819&group_id=12867 Category: Core Group: None >Status: Open Resolution: Fixed Priority: 4 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: Multi-level Java method overriding fails Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-05-07 12:24 Message: 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 / ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-03-22 12:50 Message: 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; ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-02-23 12:26 Message: 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. ---------------------------------------------------------------------- Comment By: ian west (ianzsk) Date: 2001-02-19 01:26 Message: 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. ---------------------------------------------------------------------- Comment By: Samuele Pedroni (pedronis) Date: 2000-12-16 12:52 Message: Just checked that the nasty bug is still there. It should be solved for sure, at least the stack overflow. Not analyzed yet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=222819&group_id=12867 |
|
From: <no...@so...> - 2001-07-03 11:47:24
|
Bugs item #222819, was opened at 2000-11-18 11:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=222819&group_id=12867 Category: Core Group: None >Status: Closed Resolution: Fixed Priority: 4 Submitted By: Finn Bock (bckfnn) Assigned to: Samuele Pedroni (pedronis) Summary: Multi-level Java method overriding fails Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Samuele Pedroni (pedronis) Date: 2001-07-03 04:47 Message: Logged In: YES user_id=61408 fixed (both in interp and jythonc) . Note: the code affected and related to this needs a big revision. ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-05-07 12:24 Message: 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 / ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-03-22 12:50 Message: 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; ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-02-23 12:26 Message: 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. ---------------------------------------------------------------------- Comment By: ian west (ianzsk) Date: 2001-02-19 01:26 Message: 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. ---------------------------------------------------------------------- Comment By: Samuele Pedroni (pedronis) Date: 2000-12-16 12:52 Message: Just checked that the nasty bug is still there. It should be solved for sure, at least the stack overflow. Not analyzed yet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=222819&group_id=12867 |
|
From: <no...@so...> - 2001-07-18 16:16:53
|
Bugs item #222819, was opened at 2000-11-18 11:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=222819&group_id=12867 Category: Core >Group: Fixed in 2.1a2 Status: Closed Resolution: Fixed Priority: 4 Submitted By: Finn Bock (bckfnn) Assigned to: Samuele Pedroni (pedronis) Summary: Multi-level Java method overriding fails Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Samuele Pedroni (pedronis) Date: 2001-07-03 04:47 Message: Logged In: YES user_id=61408 fixed (both in interp and jythonc) . Note: the code affected and related to this needs a big revision. ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-05-07 12:24 Message: 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 / ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-03-22 12:50 Message: 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; ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-02-23 12:26 Message: 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. ---------------------------------------------------------------------- Comment By: ian west (ianzsk) Date: 2001-02-19 01:26 Message: 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. ---------------------------------------------------------------------- Comment By: Samuele Pedroni (pedronis) Date: 2000-12-16 12:52 Message: Just checked that the nasty bug is still there. It should be solved for sure, at least the stack overflow. Not analyzed yet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=222819&group_id=12867 |