public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: java/1365: deadlock in _Jv_FindClassInCache
@ 2001-11-02 14:26 tromey
0 siblings, 0 replies; 3+ messages in thread
From: tromey @ 2001-11-02 14:26 UTC (permalink / raw)
To: apbianco, gcc-bugs, gcc-gnats, gcc-prs, java-prs, osk, tromey
Synopsis: deadlock in _Jv_FindClassInCache
Responsible-Changed-From-To: apbianco->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Wed Nov 14 10:27:21 2001
Responsible-Changed-Why:
I'm handling the PR now.
State-Changed-From-To: analyzed->closed
State-Changed-By: tromey
State-Changed-When: Wed Nov 14 10:27:21 2001
State-Changed-Why:
This has been fixed on the cvs trunk.
The fix will appear in gcj 3.1.
Duplicate class registration will cause a failure,
either a complete failure if it happens before VM initialization
is complete or a VirtualMachineError exception.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=1365&database=gcc
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: java/1365: deadlock in _Jv_FindClassInCache
@ 2001-11-02 14:28 tromey
0 siblings, 0 replies; 3+ messages in thread
From: tromey @ 2001-11-02 14:28 UTC (permalink / raw)
To: tromey; +Cc: gcc-prs
The following reply was made to PR java/1365; it has been noted by GNATS.
From: tromey@gcc.gnu.org
To: apbianco@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
gcc-prs@gcc.gnu.org, java-prs@gcc.gnu.org, osk@hem.passagen.se,
tromey@gcc.gnu.org
Cc:
Subject: Re: java/1365: deadlock in _Jv_FindClassInCache
Date: 14 Nov 2001 18:27:22 -0000
Synopsis: deadlock in _Jv_FindClassInCache
Responsible-Changed-From-To: apbianco->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Wed Nov 14 10:27:21 2001
Responsible-Changed-Why:
I'm handling the PR now.
State-Changed-From-To: analyzed->closed
State-Changed-By: tromey
State-Changed-When: Wed Nov 14 10:27:21 2001
State-Changed-Why:
This has been fixed on the cvs trunk.
The fix will appear in gcj 3.1.
Duplicate class registration will cause a failure,
either a complete failure if it happens before VM initialization
is complete or a VirtualMachineError exception.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=1365&database=gcc
^ permalink raw reply [flat|nested] 3+ messages in thread
* java/1365: deadlock in _Jv_FindClassInCache
@ 2000-12-20 12:25 osk
0 siblings, 0 replies; 3+ messages in thread
From: osk @ 2000-12-20 12:25 UTC (permalink / raw)
To: java-gnats
>Number: 1365
>Category: java
>Synopsis: deadlock in _Jv_FindClassInCache
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: apbianco
>State: analyzed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 20 12:19:18 PST 2000
>Closed-Date:
>Last-Modified: Sun Sep 10 17:40:00 PDT 2000
>Originator: Oskar Liljeblad
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
The program below gets in a deadloop when it is started.
This is probably because java.util.AbstractList is
initialized in the libgcj "main" before the class main
is actually run. (I guess AbstractList is used by some
System class or something.) As AbstractList is overriden
by the dummy-class below, havoc breaks loose.
I'm not sure this is a bug, but it would be nice if
some appropriate exception was thrown instead of
a deadlock occuring...
Oskar Liljeblad (osk@hem.passagen.se)
>How-To-Repeat:
mkdir -p java/util
echo >java/util/AbstractList.java <<__END__
package java.util;
abstract class AbstractList {
static class SubList extends AbstractList {
public SubList(AbstractList backing) { }
}
}
__END__
echo >test.java <<__END__
class test {
public static void main(String[] args) { }
}
__END__
gcj -o test --main=test *.java java/util/*.java
./test
>Fix:
The deadloop occurs in _Jv_FindClassInCache in
libjava/java/lang/natClassLoader.cc near line 345.
klass and klass->next is the same when
klass->name is something like "java.util.AbstractList$SubList".
>Release-Note:
>Audit-Trail:
Formerly PR gcj/338
State-Changed-From-To: open->analyzed
State-Changed-By: green
State-Changed-When: Sun Sep 10 12:57:49 2000
State-Changed-Why:
What's happening here is that we have a class living in both a shared library and the main program.
The AbstractList class is registered when the main program starts up. This is done through the use of the per-class static constructors. The same thing happens when the libgcj shared library is loaded. When the same class is registered twice we end up with a loop in the class cache (klass->next == klass).
Here's one way to avoid the deadloop symptom. It's difficult to say what the right thing to do is.
Index: java/lang/natClassLoader.cc
===================================================================
RCS file: /cvs/java/libgcj/libjava/java/lang/natClassLoader.cc,v
retrieving revision 1.25
diff -u -r1.25 natClassLoader.cc
--- natClassLoader.cc 2000/07/20 19:31:16 1.25
+++ natClassLoader.cc 2000/09/10 19:51:49
@@ -436,7 +436,18 @@
for (; *classes; ++classes)
{
jclass klass = *classes;
- jint hash = HASH_UTF (klass->name);
+ _Jv_Utf8Const *name = klass->name;
+ jint hash = HASH_UTF (name);
+ // In certain situations we may find ourselves registering the
+ // same class twice (but with different implementations). For
+ // instance, foo.Bar may exist in two different shared
+ // libraries. The first class registered wins in this case, and
+ // we proceed silently.
+ for (jclass k = loaded_classes[hash]; k; k = k->next)
+ {
+ if (_Jv_equalUtf8Consts (name, k->name))
+ return;
+ }
klass->next = loaded_classes[hash];
loaded_classes[hash] = klass;
From: green@cygnus.com
To: apbianco@cygnus.com, java-gnats@sourceware.cygnus.com, osk@hem.passagen.se
Cc:
Subject: Re: gcj/338
Date: 10 Sep 2000 19:57:49 -0000
Synopsis: deadlock in _Jv_FindClassInCache
State-Changed-From-To: open->analyzed
State-Changed-By: green
State-Changed-When: Sun Sep 10 12:57:49 2000
State-Changed-Why:
What's happening here is that we have a class living in both a shared library and the main program.
The AbstractList class is registered when the main program starts up. This is done through the use of the per-class static constructors. The same thing happens when the libgcj shared library is loaded. When the same class is registered twice we end up with a loop in the class cache (klass->next == klass).
Here's one way to avoid the deadloop symptom. It's difficult to say what the right thing to do is.
Index: java/lang/natClassLoader.cc
===================================================================
RCS file: /cvs/java/libgcj/libjava/java/lang/natClassLoader.cc,v
retrieving revision 1.25
diff -u -r1.25 natClassLoader.cc
--- natClassLoader.cc 2000/07/20 19:31:16 1.25
+++ natClassLoader.cc 2000/09/10 19:51:49
@@ -436,7 +436,18 @@
for (; *classes; ++classes)
{
jclass klass = *classes;
- jint hash = HASH_UTF (klass->name);
+ _Jv_Utf8Const *name = klass->name;
+ jint hash = HASH_UTF (name);
+ // In certain situations we may find ourselves registering the
+ // same class twice (but with different implementations). For
+ // instance, foo.Bar may exist in two different shared
+ // libraries. The first class registered wins in this case, and
+ // we proceed silently.
+ for (jclass k = loaded_classes[hash]; k; k = k->next)
+ {
+ if (_Jv_equalUtf8Consts (name, k->name))
+ return;
+ }
klass->next = loaded_classes[hash];
loaded_classes[hash] = klass;
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=338&database=java
From: Tom Tromey <tromey@cygnus.com>
To: green@cygnus.com
Cc: apbianco@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: gcj/338
Date: 10 Sep 2000 17:31:12 -0600
Anthony> Here's one way to avoid the deadloop symptom. It's difficult
Anthony> to say what the right thing to do is.
One idea would be to throw a LinkageError because the class is already
loaded. See ClassLoader.defineclass.
Comments on this idea?
Tom
From: Anthony Green <green@cygnus.com>
To: "'tromey@cygnus.com'" <tromey@cygnus.com>
Cc: "apbianco@cygnus.com" <apbianco@cygnus.com>,
"java-gnats@sourceware.cygnus.com" <java-gnats@sourceware.cygnus.com>
Subject: RE: gcj/338
Date: Sun, 10 Sep 2000 17:33:23 -0700
On Sunday, September 10, 2000 4:31 PM, Tom Tromey [SMTP:tromey@cygnus.com]
wrote:
> One idea would be to throw a LinkageError because the class is already
> loaded. See ClassLoader.defineclass.
>
> Comments on this idea?
Can we do this reliably at static constructor initialization time?
AG
>Unformatted:
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-11-14 18:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-02 14:26 java/1365: deadlock in _Jv_FindClassInCache tromey
-- strict thread matches above, loose matches on Subject: below --
2001-11-02 14:28 tromey
2000-12-20 12:25 osk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).