This is the mail archive of the
java-prs@sources.redhat.com
mailing list for the Java project.
gcj/338: deadlock in _Jv_FindClassInCache
- To: java-gnats at sourceware dot cygnus dot com
- Subject: gcj/338: deadlock in _Jv_FindClassInCache
- From: osk at hem dot passagen dot se
- Date: 4 Sep 2000 15:50:11 -0000
- Reply-To: osk at hem dot passagen dot se
- Resent-Cc: java-prs at sourceware dot cygnus dot com, green at cygnus dot com
- Resent-Reply-To: java-gnats@sourceware.cygnus.com, osk@hem.passagen.se
>Number: 338
>Category: gcj
>Synopsis: deadlock in _Jv_FindClassInCache
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: apbianco
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Sep 04 09:00:01 PDT 2000
>Closed-Date:
>Last-Modified:
>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:
>Unformatted: