Re: [kaffe] Bug Report: StackOverflowError and Collections

2003-10-05 Thread Dalibor Topic 
Hi Jim,

Jim Pick wrote:

Basically, LazyHashtable.contains(Object value) calls
super.contains(Object value) in Hashtable, which in Classpath's
implementation, calls Hashtable.containsValue(Object value).
Unfortunately, LazyHashTable.containsValue(Ojbect value) overrides that,
just calling calling LazyHashTable.contains(Object value) again, and we
have a loop.
Should be fixed with my latest patch. Could you cvs update and try again?

cheers,
dalibor topic


___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

Re: [kaffe] Bug Report: StackOverflowError and Collections

2003-09-09 Thread Stephen Crawley 

Jim Pick <[EMAIL PROTECTED]> wrote:
> Tom Tromey <[EMAIL PROTECTED]> wrote:
> > It isn't clear to me that this is definitively a Classpath bug.  Who's
> > to say there isn't currently-working code out there that does the
> > opposite?  The JDK docs certainly don't specify this sort of thing.

> I think it depends on how you define "what is a bug".
> 
> Sure, it's not in the spec, but Sun implemented it a certain way, and
> that gets exposed, and code (eg. Ant, and probably others) depends on
> the way it was implemented.

I agree with Jim.  From what I recall, Sun conformance testing takes the
approach that the "gold standard" for Java is not the JavaDoc but the
behaviour of their JDK reference implementations.  Assuming that we want 
to "conformant", we should follow Sun's definition of what this means.

Besides, it is unrealistic to expecting people to code applications to
assume >>only<< what the JavaDocs says.  Most people don't write code
with the JavaDoc.  If they tried to, they'd probably fail because:

  1)  the javadoc is often incomplete, occasionally misleading and
  sometimes plain wrong, and

  2)  your average joe programmer has difficulty reading/comprehending
  precise specifications.

So, this sounds like a real bug.  The way to be sure would be to distill
it onto a Mauve testcase so that it can be run against various Sun JDKs.

-- Steve



___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

Re: [kaffe] Bug Report: StackOverflowError and Collections

2003-09-09 Thread Jim Pick 
On 09 Sep 2003 10:11:27 -0600
Tom Tromey <[EMAIL PROTECTED]> wrote:

> >> Basically, LazyHashtable.contains(Object value) calls
> >> super.contains(Object value) in Hashtable, which in Classpath's
> >> implementation, calls Hashtable.containsValue(Object value).
> >> Unfortunately, LazyHashTable.containsValue(Ojbect value) overrides that,
> >> just calling calling LazyHashTable.contains(Object value) again, and we
> >> have a loop.
> 
> It isn't clear to me that this is definitively a Classpath bug.  Who's
> to say there isn't currently-working code out there that does the
> opposite?  The JDK docs certainly don't specify this sort of thing.

I think it depends on how you define "what is a bug".

Sure, it's not in the spec, but Sun implemented it a certain way, and
that gets exposed, and code (eg. Ant, and probably others) depends on
the way it was implemented.

Since it's unlikely that any Java(tm) branded JVM is going to use an
alternate implementation, people are going to unwittingly rely on these
hidden dependencies.

It's going to be really difficult to try to mount a campaign to try to
convince people to code to the spec (if you can call the Javadocs a
spec), vs. coding to the implementation, especially when only 0.0001% of
Java developers use ours.  It might be easier to just admit defeat, and
change our implementation when it doesn't match.

> I think it would be easy to change ant to be robust in the face of any
> implementation of Hashtable.
> 
> 
> What version of ant is this?  I don't see this file in the ant in rhug
> (1.5).

I stumbled across it in Ant from CVS dated '4/28/2003 00:00 UTC' (the
newer CVS stuff doesn't work for me yet because of nio).  I'm trying to
build a regression test based on Jakarta Gump (2gigs of code!).

Cheers,

 - Jim

___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

Re: [kaffe] Bug Report: StackOverflowError and Collections

2003-09-09 Thread Dalibor Topic 

--- Tom Tromey <[EMAIL PROTECTED]> wrote:
> >> Basically, LazyHashtable.contains(Object value) calls
> >> super.contains(Object value) in Hashtable, which in Classpath's
> >> implementation, calls Hashtable.containsValue(Object value).
> >> Unfortunately, LazyHashTable.containsValue(Ojbect value) overrides that,
> >> just calling calling LazyHashTable.contains(Object value) again, and we
> >> have a loop.
> 
> It isn't clear to me that this is definitively a Classpath bug.  Who's
> to say there isn't currently-working code out there that does the
> opposite?  The JDK docs certainly don't specify this sort of thing.

this is a typical java library bug, and I've both produced and fixed a couple
of those myself ;) You get an infinite recursion through calling overridden
methods. Class A in library implements public methods b and c, where b
internally (and of course undocumentedly ;) calls c. Class B from some user of
the library extends A and overrides c to call b. When the user calls the method
b of class B it goes straight into an infinite loop.

The fix is to avoid calling overridable methods from overridable methods, and
to delegate those calls to internal, non-overridable versions of the methods.

cheers,
dalibor topic

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

Re: [kaffe] Bug Report: StackOverflowError and Collections

2003-09-09 Thread Tom Tromey 
>> Basically, LazyHashtable.contains(Object value) calls
>> super.contains(Object value) in Hashtable, which in Classpath's
>> implementation, calls Hashtable.containsValue(Object value).
>> Unfortunately, LazyHashTable.containsValue(Ojbect value) overrides that,
>> just calling calling LazyHashTable.contains(Object value) again, and we
>> have a loop.

It isn't clear to me that this is definitively a Classpath bug.  Who's
to say there isn't currently-working code out there that does the
opposite?  The JDK docs certainly don't specify this sort of thing.

I think it would be easy to change ant to be robust in the face of any
implementation of Hashtable.


What version of ant is this?  I don't see this file in the ant in rhug
(1.5).

Tom

___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

Re: [kaffe] Bug Report: StackOverflowError and Collections

2003-09-02 Thread Jim Pick 
On Tue, 2 Sep 2003 19:49:38 -0700
Jim Pick <[EMAIL PROTECTED]> wrote:

> On Fri, 29 Aug 2003 18:14:00 -0700
> "Jim Pick" <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> > 
> > I'm running into problems building ant from CVS (4/28/2003 00:00 UTC),
> > on an x86 Linux machine with the defaults (jthreads/jit3).  It fails
> > like this:
> > 
> > ... Building Ant Distribution
> > Buildfile: build.xml
> > 
> > BUILD FAILED
> > java.lang.StackOverflowError
> ><>
> > 
> > Total time: 0 seconds
> > java.lang.StackOverflowError
> ><>
> > ... Failed Building Ant Distribution !
> > 
> > It used to work.  I chased it down to this particular change (the
> > Classpath Collections merge).  I tried increasing the stack size using
> > the -ss option, but it didn't seem to help.
> > 
> > I'll try to debug this when I get time, but I thought I'd report it
> > first.
> 
> Okay, I did some more legwork, and it appears that the problem appears
> because Ant creates a subclass of Hashtable called
> org.apache.tools.ant.util.LazyHashtable, which worked nicely with our
> old implementation of Hashtable, but not with the new Classpath-based
> implementation of Hashtable.
> 
> Basically, LazyHashtable.contains(Object value) calls
> super.contains(Object value) in Hashtable, which in Classpath's
> implementation, calls Hashtable.containsValue(Object value).
> Unfortunately, LazyHashTable.containsValue(Ojbect value) overrides that,
> just calling calling LazyHashTable.contains(Object value) again, and we
> have a loop.
> 
> I'd post a snippet of the stack trace, but I had to use gdb and
> -Xxdebug, so all the symbols are mangled and it's ugly.  :-)
> 
> The old Kaffe implementation of Hashtable didn't have the problem, since
> it used a private HashMap, compare below:
> 
> LazyHashtable:
> 
> http://cvs.apache.org/viewcvs/ant/src/main/org/apache/tools/ant/util/LazyHashtable.java?rev=1.6&content-type=text/vnd.viewcvs-markup
> 
> Classpath's Hashtable
> 
> http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/Hashtable.java?rev=1.28&content-type=text/vnd.viewcvs-markup
> 
> Our old Hashtable:
> 
> http://www.kaffe.org/cgi-bin/viewcvs.cgi/kaffe/libraries/javalib/java/util/Hashtable.java?rev=1.26&content-type=text/vnd.viewcvs-markup
> 
> I don't know if Kaffe's old Hashtable implementation is more proper or
> not, but at least it worked.  :-)
> 
> I'll cc: this to the classpath list.

Oops, I must have left off the cc:, trying again.

Cheers,

 - Jim

___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

Re: [kaffe] Bug Report: StackOverflowError and Collections

2003-09-02 Thread Jim Pick 
On Fri, 29 Aug 2003 18:14:00 -0700
"Jim Pick" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I'm running into problems building ant from CVS (4/28/2003 00:00 UTC),
> on an x86 Linux machine with the defaults (jthreads/jit3).  It fails
> like this:
> 
> ... Building Ant Distribution
> Buildfile: build.xml
> 
> BUILD FAILED
> java.lang.StackOverflowError
><>
> 
> Total time: 0 seconds
> java.lang.StackOverflowError
><>
> ... Failed Building Ant Distribution !
> 
> It used to work.  I chased it down to this particular change (the
> Classpath Collections merge).  I tried increasing the stack size using
> the -ss option, but it didn't seem to help.
> 
> I'll try to debug this when I get time, but I thought I'd report it
> first.

Okay, I did some more legwork, and it appears that the problem appears
because Ant creates a subclass of Hashtable called
org.apache.tools.ant.util.LazyHashtable, which worked nicely with our
old implementation of Hashtable, but not with the new Classpath-based
implementation of Hashtable.

Basically, LazyHashtable.contains(Object value) calls
super.contains(Object value) in Hashtable, which in Classpath's
implementation, calls Hashtable.containsValue(Object value).
Unfortunately, LazyHashTable.containsValue(Ojbect value) overrides that,
just calling calling LazyHashTable.contains(Object value) again, and we
have a loop.

I'd post a snippet of the stack trace, but I had to use gdb and
-Xxdebug, so all the symbols are mangled and it's ugly.  :-)

The old Kaffe implementation of Hashtable didn't have the problem, since
it used a private HashMap, compare below:

LazyHashtable:

http://cvs.apache.org/viewcvs/ant/src/main/org/apache/tools/ant/util/LazyHashtable.java?rev=1.6&content-type=text/vnd.viewcvs-markup

Classpath's Hashtable

http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/Hashtable.java?rev=1.28&content-type=text/vnd.viewcvs-markup

Our old Hashtable:

http://www.kaffe.org/cgi-bin/viewcvs.cgi/kaffe/libraries/javalib/java/util/Hashtable.java?rev=1.26&content-type=text/vnd.viewcvs-markup

I don't know if Kaffe's old Hashtable implementation is more proper or
not, but at least it worked.  :-)

I'll cc: this to the classpath list.

Cheers,

 - Jim


 

___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

[kaffe] Bug Report: StackOverflowError and Collections

2003-08-30 Thread Jim Pick 
Hi,

I'm running into problems building ant from CVS (4/28/2003 00:00 UTC),
on an x86 Linux machine with the defaults (jthreads/jit3).  It fails
like this:

... Building Ant Distribution
Buildfile: build.xml

BUILD FAILED
java.lang.StackOverflowError
   <>

Total time: 0 seconds
java.lang.StackOverflowError
   <>
... Failed Building Ant Distribution !

It used to work.  I chased it down to this particular change (the
Classpath Collections merge).  I tried increasing the stack size using
the -ss option, but it didn't seem to help.

I'll try to debug this when I get time, but I thought I'd report it
first.

Cheers,

 - Jim


On Tue, 12 Aug 2003 16:02:20 -0700
"Kaffe CVS" <[EMAIL PROTECTED]> wrote:

> 
> CVSROOT:  /cvs/kaffe
> Module name:  kaffe
> Changes by:   hkraemer03/08/12 16:02:20
> 
> Modified files:
>   .  : ChangeLog 
>   libraries/javalib: Klasses.jar.bootstrap Makefile.am Makefile.in 
>   libraries/javalib/profiles/default: core.files 
>   libraries/javalib/profiles/allatonce: all.files 
>   libraries/javalib/java/lang: Float.java Double.java 
>   libraries/javalib/java/util: AbstractListIterator.java 
>AbstractMap.java 
>AbstractSequentialList.java 
>AbstractSet.java ArrayList.java 
>Arrays.java Collections.java 
>Dictionary.java HashMap.java 
>HashSet.java Hashtable.java 
>LinkedList.java TreeMap.java 
>TreeSet.java Vector.java 
>WeakHashMap.java 
> Added files:
>   libraries/javalib/java/util: IdentityHashMap.java 
>LinkedHashMap.java 
>LinkedHashSet.java 
> Removed files:
>   libraries/javalib/java/util: LinkedListIterator.java 
> 
> Log message:
> * libraries/javalib/java/lang/Float.java,
> libraries/javalib/java/lang/Double.java:
> (compare) new methods found in jdk1.4
> 
> * libraries/javalib/java/util/AbstractMap.java,
> libraries/javalib/java/util/AbstractSequentialList.java,
> libraries/javalib/java/util/AbstractSet.java,
> libraries/javalib/java/util/ArrayList.java,
> libraries/javalib/java/util/Arrays.java,
> libraries/javalib/java/util/Collections.java,
> libraries/javalib/java/util/Dictionary.java,
> libraries/javalib/java/util/HashMap.java,
> libraries/javalib/java/util/HashSet.java,
> libraries/javalib/java/util/Hashtable.java,
> libraries/javalib/java/util/IdentityHashMap.java,
> libraries/javalib/java/util/LinkedHashMap.java,
> libraries/javalib/java/util/LinkedHashSet.java,
> libraries/javalib/java/util/LinkedList.java,
> libraries/javalib/java/util/TreeMap.java,
> libraries/javalib/java/util/TreeSet.java,
> libraries/javalib/java/util/Vector.java,
> libraries/javalib/java/util/WeakHashMap.java:
> Merged in part of the collection framework from GNU
> Classpath
> 
> * libraries/javalib/java/util/LinkedListIterator.java:
> removed
> 
> * libraries/javalib/Klasses.jar.bootstrap,
> libraries/javalib/Makefile.am,
> libraries/javalib/Makefile.in:
> regenerated
> 
> * libraries/javalib/profiles/allatonce/all.files,
> libraries/javalib/profiles/default/core.files:
> added IdentityHashMap, LinkedHashMap and LinkedHashSet
> 
> 
> ___
> kaffe mailing list
> [EMAIL PROTECTED]
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe