Re: [kaffe] kaffe/kaffevm/readClass.c: Should class version 1.5 be supported?
Hi Ito,
Thanks for making the test. Yes. Kaffe normally supports 1.5 class
files. Though the new information are not necessarily yet well
integrated with the VM core they should be exported to classpath.
The patch looks right to me. Go ahead !
Regards,
Guilhem.
Ito Kazumitsu wrote:
Hi,
I happened to find that, luckily, a class file of version 1.5
compiled by Sun's javac from source like this:
import java.util.ArrayList;
public class Test1 {
@Deprecated
public static void main(String[] args) {
ArrayListString a = new ArrayListString();
a.add(aaa);
for (String s : a) System.out.println(s);
}
}
can be run with Kaffe normally.
On the other hand, kaffe/kaffevm/readClass.c seems to be trying
to prevent class file version 1.5 from running.
But UnsupportedClassVersionError does not occur because of the
bug in kaffe/kaffevm/readClass.c of not returning NULL.
The question is whether UnsupportedClassVersionError should be
thrown in this case or the class file should be run normally.
I prefer the latter, and this is my proposed patch.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] WidgetsDemo not found in java.lang.ClassLoader
Fu, Elva wrote:
Hi all,
I installed kaffe-1.1.6 on Fedora 4 , but it failed when I try to
execute awt demo. My install steps as following:
$ ./configure
$ make
$ make install
Everything seems ok. Then I add kaffe path into PATH:
$ export PATH=$PATH:/usr/local/kaffe/bin
When I try to execute WidgetsDemo, it fails .
$ cd test/awt/WidgetsDemo
$ kaffe WidgetsDemo
/-/
/ java.lang.ClassNotFoundException: WidgetsDemo not found in
java.lang.ClassLoader$1{urls=[file:~/kaffe/kaffe-1.1.6/test/awt/WidgetsDemo/./],
parent=null}/
Anyone experience the same?
Really appreciate your help!
Elva Fu
Hi Elva,
WidgetsDemo is not compiled by default. You have to run javac
WidgetsDemo.java first and then use kaffe WidgetsDemo.
Regards,
Guilhem.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Building Kaffe!
Hi Vlad, You must not configure anything else but the top directory. The other configure are started by that one. The problem you are getting is because jikes has not been detected. Try installing jikes with 'apt-get install jikes' Guilhem. vlad wrote: Hi, Because I am getting more and more obscured by even more details, I wanna tell you what I did to attain here: - first I checked out the 'kaffe' module from cvs.kaffe.org:/cvs/kaffe (got it not from the ftp source) - when running ./configure it fails with the message: configure: error: GTK+ peers requested but no X library available ... to fix this one I run configure with --without-x --without-classpath-gtk-awt --without-kaffe-qt-awt --without-kaffe-x-awt --disable-gtk-peer ... now configure succeeds! (is there any other fixup?) - when running 'make', it enters into libraries/javalib/external/classpath/lib and fails on: Adding java source files from srcdir '..'. Adding java source files from VM directory ../vm/reference F -bootclasspath '' -extdirs '' -sourcepath '' --classpath ../vm/reference:..:../external/w3c_dom:../external/sax:../external/relaxngDatatype:.:: -d . @classes make[3]: F: command not found make[3]: *** [compile-classes] error 127 - In '/libraries/javalib/external/classpath/' I've found another configure, which I executed with the same parameters as described above! I run make again and it led to the previous error with the .stamp target Now I have cleaned all Makefile.in files in the tree and updated then with cvs -qz3 update ... Each make call leads now to the make[3]: F: command not found error as described above ... Do you have an idea how I could manage it? What happens? Thank you for any reply in advance! Best Regards Vladimir Guilhem Lavaux wrote: Hi, The target to produce this .stamp file is present in libraries/javalib/vmspecific/Makefile.in (and Makefile too of course). It is generated by newer automake. Maybe automake has tried to rebuild your Makefiles ? I suggest you clean up Makefile.in in your tree and reupdate from cvs using 'cvs -qz3 update' and see if it improves the situation. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] new problem!
Hi, The target to produce this .stamp file is present in libraries/javalib/vmspecific/Makefile.in (and Makefile too of course). It is generated by newer automake. Maybe automake has tried to rebuild your Makefiles ? I suggest you clean up Makefile.in in your tree and reupdate from cvs using 'cvs -qz3 update' and see if it improves the situation. Regards, Guilhem. vlad wrote: Thank you for your help Guilhem! I've installed those packages and ./configure functioned so far! Anyway 'make' did not finish later without errors ... In the directory 'libraries/javalib/vmspecific' make fails to find classdist_vminterface.stamp required by the kaffe-vminterface.jar (target). Is there any special config parameter which I have missed, or something like that ??? I looked into the Makefile and discovered this: $(CLASSFILE): classdist_vminterface.stamp rm -f $(CLASSFILE) $(JAR_CMD1) $(JAR_CMD2) $(JAR_CMD3) I cannot find any target 'classdist_vminterface.stamp' ?!?! Is it normal, that the JAR-CMDs point to a non existent 'lib' directory in libraries/javalib/vmspecific/Makefile ? For example: JAR_CMD1 = ($(FASTJAR) cf $(CLASSFILE) -C $(LIBDIR) $(SRCDIRS)) would be (according to the values of the variables): /usr/bin/fastjar cf kaffe-vminterface.jar -C lib org but lib does not exist there! What goes wrong here? Of course I could easily change the value of LIBDIR=. (current dir) and probably it would function... Regards Vladimir Guilhem Lavaux wrote: Hi Vlad, If you use --disable-gconf-peer your problem should vanish. But if you have ubuntu 6.06 then you should be able to install the development package of gconf2 and gtk using apt-get install libgconf2-dev libgtk2.0-dev Regards, Guilhem. vlad wrote: Hello, I've fixed my previous problem so far by using --disable-gtk-peer with configure. Finally I used the following configuration on ./configure: ./configure --build=i686-linux --enable-xscale --without-x --disable-alsatest --disable-esdtest --disable-sound --enable-pure-java-math --without-classpath-gtk-awt --without-kaffe-qt-awt --without-kaffe-x-awt --with-threads=unix-pthreads --with-engine=intrp --enable-debug --enable-xdebugging --disable-boehm-gc-configuration build_alias=i686-linux --enable-ltdl-convenience --disable-core-jni --disable-examples --cache-file=/dev/null --srcdir=. --disable-gtk-peer --enable-gcj I am not sure about the rightness of those options according to my system configuration. Anyway I got a new error: checking for pkg-config... /usr/bin/pkg-config checking for gconf-2.0 = 2.11.2... Package gconf-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gconf-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gconf-2.0' found configure: error: Library requirements (gconf-2.0 = 2.11.2) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. My system is: Ubuntu 6.06.1 LTS Linux version 2.6.15-27-386 gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) autoconf (GNU Autoconf) 2.59 automake (GNU automake) 1.4-p6 pkg-config --version = 0.20 gconf2 (2.14.0) is also installed ... please tell me if you know, how I could fix this one. Thanks in advance, Regards Vladimir ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] new problem!
Hi Vlad, If you use --disable-gconf-peer your problem should vanish. But if you have ubuntu 6.06 then you should be able to install the development package of gconf2 and gtk using apt-get install libgconf2-dev libgtk2.0-dev Regards, Guilhem. vlad wrote: Hello, I've fixed my previous problem so far by using --disable-gtk-peer with configure. Finally I used the following configuration on ./configure: ./configure --build=i686-linux --enable-xscale --without-x --disable-alsatest --disable-esdtest --disable-sound --enable-pure-java-math --without-classpath-gtk-awt --without-kaffe-qt-awt --without-kaffe-x-awt --with-threads=unix-pthreads --with-engine=intrp --enable-debug --enable-xdebugging --disable-boehm-gc-configuration build_alias=i686-linux --enable-ltdl-convenience --disable-core-jni --disable-examples --cache-file=/dev/null --srcdir=. --disable-gtk-peer --enable-gcj I am not sure about the rightness of those options according to my system configuration. Anyway I got a new error: checking for pkg-config... /usr/bin/pkg-config checking for gconf-2.0 = 2.11.2... Package gconf-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gconf-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gconf-2.0' found configure: error: Library requirements (gconf-2.0 = 2.11.2) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. My system is: Ubuntu 6.06.1 LTS Linux version 2.6.15-27-386 gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) autoconf (GNU Autoconf) 2.59 automake (GNU automake) 1.4-p6 pkg-config --version = 0.20 gconf2 (2.14.0) is also installed ... please tell me if you know, how I could fix this one. Thanks in advance, Regards Vladimir ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Moving kaffe.org server
Hi Jim, Thank you very much for the move ! You are supporting kaffe's hardware for such a long time now. :-) Cheers ! Guilhem. Jim Pick wrote: Jim Pick wrote: In about half an hour, I'm planning to move pogo.kaffe.org from it's current dedicated machine to a new Xen session on one of my new servers. It's all moved. If you see anything that's broken, please send me an email. Cheers, - Jim ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Assertion fails in JNI access to Weak references.
Tim Bevan wrote: I can reduce my real problem to the attached class and native metbod. We are simply creating a weak reference to the class then releasing it once we have finished with it. Deleting the weak reference aborts the program! Hello, world from java first Got weak reference kaffe-bin: jni-refs.c:290: KaffeJNI_DeleteWeakGlobalRef: Assertion `((main_collector)-ops-getObjectIndex)((Collector*)(main_collector), ( ref)) == KGC_ALLOC_VMWEAKREF' failed. Program received signal SIGABRT, Aborted. Hi Tim, I see... this is a minor bug (mean easily fixable). In DeleteWeakGlobalRef we need to move the unveil operation before checking the actual type of the hidden pointer. I am going to do that now. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Assertion fails in JNI access to Weak references.
Tim Bevan wrote: I can reduce my real problem to the attached class and native metbod. We are simply creating a weak reference to the class then releasing it once we have finished with it. Deleting the weak reference aborts the program! Hello, world from java first Got weak reference kaffe-bin: jni-refs.c:290: KaffeJNI_DeleteWeakGlobalRef: Assertion `((main_collector)-ops-getObjectIndex)((Collector*)(main_collector), ( ref)) == KGC_ALLOC_VMWEAKREF' failed. Program received signal SIGABRT, Aborted. Hi again, The bug was a bit more subtle but it should be fixed by now in CVS. Please tell me if something else goes wrong. Cheers, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Garbage Collection Questions
Hi Michael, The author of JamVM is trying to implement this behaviour. It is strongly in development and probably CPU intensive when the heap is shrinked because you have to update all pointers in your memory. This is a somewhat complicated procedure as you have to scan the heap for all pointers (or to keep them at hand for future modification) and update your data structures consequently so the development/debugging stage will be quite high too. My opinion is that it is a lower priority for kaffe at the moment as we have some other features to implement before looking into this area (performance, portability and better implementation of the basic java vm standard). If you feel sufficiently confident however you are welcome to submit something about it. ;-) Cheers, Guilhem. Michael Franz wrote: Hi, I have gotten my answers on IRC, but thought I would also ask here. Some background on my problem. I have a need for a Java application to load a large amount of data. Larger than is normal, I can load it into the JVM my using the correct -Xmx values. The issues is that after I have loaded the data and performed whatever logic I need to I want to discard the memory that was used. The JVM will garbage collect the objects, but the JVM has allocated the largest amount of memory it could from the OS. What I want to occur is to have the JVM (eventually) release this memory back to the OS. It would not have to be immediate, but it should be release within a reasonable amount of time. From my research Sun's implementation does not ever release memory back to the OS. I guess for server side processes this is ok, but for a desktop application that needs to play well with other applications (not all Java) it is not ideal. The garbage collector can release the memory. What kind of algorithms would be good candidates for determining when and how much should be released? Has anyone done and research on this topic? Or actually implemented this type of functionality in a branched version of Kaffe? Is there any JVM that currently does this? Michael ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Bug in garbage collector
Hi pancake,
What version of kaffe are you using ? CVS ? I am getting a right OOM
error when trying to call System.out.println. This is normal because
the object o may not yet be relaxed even if you put 'o = null'. What
sort of assertion failure do you get ?
I would expect something thrown by the just-in-time because it is still
not completely rock solid relative to OOM.
Regards,
Guilhem.
pancake wrote:
afaik kaffe and other VMs are vulnerable to this code. But kaffe just prints an
assert before die. Could be possible to fix this stuff on the garbage
collector? or just exit before dump?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4944300
public class HardJVMCrash {
static Object o = null;
public static void main(String[] args) {
(new MemApplet()).doit();
}
void doit () {
while (true) try {
Object[] oarr = {o}; o = oarr;
} catch (Throwable t) {
o = null;
System.out.println(Wurfgeschoss: +t);
}
}
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Building of fastjar severely broken
Michael Koch wrote: Hello list, I tried current CVS and it failed when building fastjar. There were several problems which I tried to fix locally but failed. There are even different errors when building --with-system-zlib or with the in-tree zlib. I used $builddir == $srcdir if that matters. Cheers, Michael Hi Michael ! I am not getting any error when I build either with $builddir == $srcdir or $builddir != $srcdir. Anything you can say to help us ? Thanks, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] AIX, PPC and endianness isues
Dalibor Topic wrote: On Wed, 2006-04-05 at 09:29 +0200, Riccardo wrote: Hello, I was trying to compile kaffe on AIX 4.2 with gcc on PowerPC. The setup is similar to the one I used at home where I experienced also endianness issues which I fixed at the time, I did not check if classpath lost my fixes, if they were never commited. Hi Riccardo, could you file a bug report about that in the Classpath bug tracker, and attach your patch there? Chances are it was lost during the big merge, when we switched to using the pure upstream code. cheers, dalibor topic Hi Riccardo Dalibor, Yes. It's probably linked to my old patch which was removing everything in one of the config files of fdlibm except the autoconf macros. It was not advised to do so by Tom Tromey as some architectures have weird endianness combinations... so maybe we should have a better patch here. Cheers, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] A GC question
Hi,
First, the GC is scanning all stacks including the native stacks looking
for references to GC objects which have been allocated using gcMalloc.
So the only point which poses problems is obj = gcMalloc at the moment
of the =. In the facts it is not a problem because the thread is
suspended in two ways:
* the thread is calling itself some function and in that case we take
care of flushing the registers to the stack.
* the thread is suspended using a signal handler which causes also the
registers to be moved to the stack during all the time we are in the
signal handler.
So there must not be any problems here.
Regards,
Guilhem.
Ceyhun ÖZGÜN wrote:
Hi,
I have downloaded the sources and I was looking sources.
I have a question in my mind about garbage collection.
softcall_new(stack(0), class_object());
#defined softcall_new(r, t)(r)-v.taddr = soft_new(t)
soft_new(Hjava_lang_Class* c)
{
Hjava_lang_Object* obj;
errorInfo info;
if (c-state != CSTATE_COMPLETE processClass(c,
CSTATE_COMPLETE, info) == false) {
goto bad;
}
obj = newObjectChecked(c, info);
if (obj == 0) {
goto bad;
}
DBG(NEWINSTR,
dprintf(New object of type %s (%d,%p)\n,
c-name-data, c-bfsize, obj); )
return (obj);
bad:
throwError(info);
return (0);
}
In the source above it allocates an object and pushes it to the stack.
My question is, what if the thread that allocated the object is preempted
right after the allocation and before pushing it to the stack.
And scheduler switches to an another thread and that thread needs
garbage collection.
The garbage collector searches the roots (stack and frames etc) for
references and it can not find any references because obj reference it
is not pushed on the stack yet.
So collector collects the newly allocated object and obj pointer in
first thread becomes a ghost pointer. And later first thread runs and
uses an deallocated area, possibly an area that belongs to an another
object.
And this situation is very bad.
I have a solution in my mind, but I think it is not the best solution.
Marking the object as NOT_USED in allocation and clearing that mark
first access (assigning to stack, a local var, or a field of
class/object).
I have looked at Sun JDK sources (1.3, 1.4) and I did not see any
workaround for this.
What do you think?
Thanks for advance.
Ceyhun ÖZGÜN
_
Siz siz olun MSN'den hava durumunu ögrenmeden evden çikmayin!
http://www.msn.com.tr/havadurumu/
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] threads problem
Hi Ioannis, This is good news that at least the fix seems to correct most of the problems. Concerning the cpu usage with pthreads I expect it is correct that it really eats all the CPU (actually your test is meant to no ? :-)) The problem with jthreads is a bit more worrying. We really need to investigate this issue. I will try to run the same tests for as long on some computer I have to check if it is reproduceable. Good luck with cross-compilation ! Regards, Guilhem. Ioannis Liverezas wrote: Hi Guilhem, I 've tested your fix on x86 with pthreads and it has been running for a whole day. On the other hand It seems that it generates high CPU usage and the system seems almost frozen. I could hardly move the mouse pointer. The testing host is a Centrino 1.6GHz laptop. I 've also tested x86 with jthreads.The jthreads system runs smoother and stresses the cpu less, but after a lot of hours (15.5) it failed: Thread: Time100 :sync :1 Alive:15/03/2006, 06:20:25.843 Test started at 14/03/2006, 14:53:09.864 SLEEP INTERRUPTED TimeA15000: i = 111100499 Thread: TimeA15000 :sync :1 Alive:15/03/2006, 06:20:26.419 kaffe-bin: jthread.c:2452: jmutex_unlock: Assertion `tid-status != 1' failed. Aborted Maybe I should dedicate a pc to run the pthreads test for some days to make sure that it is ok. I 'm trying to crosscompile and try on ARM (PXA 255), but I face some difficulties, possibly with zlib. I 'll let you know as soon as I make some progress with cross compiling Regards, Ioannis Liverezas ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] JNI Memory leak
Hi Fernando,
ExceptionOccured() returns a reference to the exception object. The
object is pushed on the local reference table (as do some other VM,
which is logical as it is a reference). You should use ExceptionCheck
instead: it returns a boolean which is true if an exception occured and
no reference is added in the table. I know that Sun's JVM has a pretty
large local reference table but it is referenced in the official
documentation that the table by default should have a size of 16. The
table can be dynamically growed using EnsureLocalCapacity.
Regards,
Guilhem.
Fernando Silveira wrote:
Hi,
I'm developing a JNI library to work with Kaffe and I'm having a kind of
memory leak issue.
Sometimes my lib needs to instantiate Java objects and call some
methods. If the objects are created and the methods are called with
success (without exceptions or errors) everything works fine. Sometimes
the JNI library needs to try to call an inexistant method and if the
method does not exist, it must not return to the JVM and must retry to
call other methods.
The issue occurs when it calls many times the GetMethodID() function and
it returns exceptions: Kaffe shows the following error:
FATAL ERROR: No more room for local references
I know this happens when I don't DeleteLocalRef() everything I have
created, but this situation seems to be different. The following code
proves what I'm trying to say:
jmethodID
test_GetMethodID(JNIEnv *jenv, jclass jcls, const char *name,
const char *sig)
{
jmethodID jmid;
/* Force java.lang.NoSuchMethodError error. */
name = NoSuchMethod;
do {
jmid = (*jenv)-GetMethodID(jenv, jcls, name, sig);
if ((*jenv)-ExceptionOccurred(jenv)) {
(*jenv)-ExceptionDescribe(jenv);
(*jenv)-ExceptionClear(jenv);
}
} while (jmid == 0);
return jmid;
}
This function causes many exceptions and a final FATAL ERROR: No more
room for local references message.
I'm not sure but I think SUN JVM and SableVM also behaves this way,
because I can see the JVM memory growing up slowly when I call this
function but they don't limit the reference room size.
I tried Google and all the JNI documentation I have but I could not find
anything related to this. Am I missing something or doing something
wrong? Can't I call a lot of GetMethodID() with invalid method names? I
hope you can give me a hint or solution for my problem.
Thanks a lot.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: jthreads problem?
Hi Ioannis, I have downloaded the file. However I am not sure I will be able to reproduce your exact system state and this is a problem because core dumps depends on the exact libc, the exact gcc, ... So probably _I_ will not be able to exploit it. However _you_ can. ;-) I can guide you if you need. You can also come on irc.freenode.net (channel #kaffe). I'll probably be there on sunday. I'll try to produce the same error too. Regards, Guilhem. Ioannis Liverezas wrote: Hi Guilhem, I followed your instructions and produced a core dump. The problem appeared immediately (~5minutes), possibly because I use jthreads. This time I used the latest cvs. The file size of the core dump is 31MB, and you can download it from the following link: http://skylab.inaccessnetworks.com/misc-downloads/kaffe-core.13590 After downloading the file inform me as soon as possible in order to remove it from the server. I also attached to this mail the options that I pass to configure I noticed that I forgot to CC to kaffe@kaffe.org my previous mails to you and as reasonable you replied only to me. So if it is ok with you, CC your reply to this mail to the mailing list, so that anybody can follow this thread. Best regards, Ioannis Liverezas On Thursday 09 February 2006 22:54, you wrote: Hi Ioannis, Anyway I think the two problems may be related. The lists are badly trashed sometimes. I fear the synchronization has some problems in locks.c/getHeavyLock. The problem is that I need a proof of it and it's hard to get it as it's about thread concurrency. :-/ If you can have more information then I'll take them with pleasure. Please try to get a core dump (ulimit -c unlimited or unlimit on tcsh) and use a kaffe compiled with '-O0'. That way we'll be able to examine the full status of kaffe. Regards, Guilhem. Ioannis Liverezas wrote: Hi Guilhem, I 'll check the test with the current cvs version of kaffe. However, what was the version that you used in order to reproduce the problem? It seems strange that you could not reproduce the bug. Also keep in mind that the time that the problem needs in order to appear is random, varying from 10minutes to a couple of hours. I will run some tests in order to provide you with some feedback. On Thursday 09 February 2006 19:09, you wrote: Ioannis Liverezas wrote: Hi all, Any progress made with the jthreads problem? Last post about this problem was on 13/01/2006. It's my first priority currently. I didn't manage to reproduce the problem with jthreads atm however pthreads has a really painful bug. For some reason the lists of the locking subsystem are sometimes completely crashed. I think I'll manage to have some results soon though (~ 1 week). Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: jthreads problem?
Ioannis Liverezas wrote: Hi all, Any progress made with the jthreads problem? Last post about this problem was on 13/01/2006. It's my first priority currently. I didn't manage to reproduce the problem with jthreads atm however pthreads has a really painful bug. For some reason the lists of the locking subsystem are sometimes completely crashed. I think I'll manage to have some results soon though (~ 1 week). Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): ALSA-lib fix
Hi George, Try to grab the file directly. It is pretty much certain that the patch which has been sent to the ML has been modified by the SMTP servers. http://www.kaffe.org/cgi-bin/viewcvs.cgi/*checkout*/kaffe/libraries/clib/sound/alsa/constants_check.h?rev=1.2 Regards, Guilhem. George P Nychis wrote: I can't get this patch to work: [EMAIL PROTECTED] ~/school/Kaffe/kaffe-1.1.6 $ patch -p1 alsapatch patching file ChangeLog Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej patching file libraries/clib/sound/alsa/constants_check.h Hunk #1 FAILED at 136. 1 out of 1 hunk FAILED -- saving rejects to file libraries/clib/sound/alsa/constants_check.h.rej [EMAIL PROTECTED] ~/school/Kaffe/kaffe-1.1.6 $ cat libraries/clib/sound/alsa/constants_check.h.rej *** *** 136,143 assert(SND_SEQ_PRIORITY_HIGH == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_PRIORITY_HIGH); assert(SND_SEQ_PRIORITY_MASK == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_PRIORITY_MASK); assert(SND_SEQ_CLIENT_SYSTEM == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_CLIENT_SYSTEM); assert(SND_SEQ_CLIENT_DUMMY == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_CLIENT_DUMMY); assert(SND_SEQ_CLIENT_OSS == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_CLIENT_OSS); /* assert(SND_SEQ_FILTER_BROADCAST == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_FILTER_BROADCAST); */ /* assert(SND_SEQ_FILTER_MULTICAST == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_FILTER_MULTICAST); */ /* assert(SND_SEQ_FILTER_BOUNCE == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_FILTER_BOUNCE); */ --- 136,147 assert(SND_SEQ_PRIORITY_HIGH == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_PRIORITY_HIGH); assert(SND_SEQ_PRIORITY_MASK == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_PRIORITY_MASK); assert(SND_SEQ_CLIENT_SYSTEM == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_CLIENT_SYSTEM); + #ifdef SND_SEQ_CLIENT_DUMMY assert(SND_SEQ_CLIENT_DUMMY == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_CLIENT_DUMMY); + #endif + #ifdef SND_SEQ_CLIENT_OSS assert(SND_SEQ_CLIENT_OSS == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_CLIENT_OSS); + #endif /* assert(SND_SEQ_FILTER_BROADCAST == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_FILTER_BROADCAST); */ /* assert(SND_SEQ_FILTER_MULTICAST == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_FILTER_MULTICAST); */ /* assert(SND_SEQ_FILTER_BOUNCE == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_FILTER_BOUNCE); */ PatchSet 7095 Date: 2006/01/18 07:37:39 Author: guilhem Branch: HEAD Tag: (none) Log: ALSA-lib fix Members: ChangeLog:1.4615-1.4616 libraries/clib/sound/alsa/constants_check.h:1.1-1.2 Index: kaffe/ChangeLog diff -u kaffe/ChangeLog:1.4615 kaffe/ChangeLog:1.4616 --- kaffe/ChangeLog:1.4615 Sun Jan 15 02:55:30 2006 +++ kaffe/ChangeLog Wed Jan 18 07:37:39 2006 @@ -1,3 +1,9 @@ +2006-01-14 Guilhem Lavaux [EMAIL PROTECTED] + + * libraries/clib/sound/alsa/check_constants.h: Check + for the macro definition because using the assert to check +the value (needed for alsa-lib-1.0.11-rc2). + 2006-01-14 Dalibor Topic [EMAIL PROTECTED] * README, configure.ac: Bumped version to 1.1.7-rc1. Index: kaffe/libraries/clib/sound/alsa/constants_check.h diff -u kaffe/libraries/clib/sound/alsa/constants_check.h:1.1 kaffe/libraries/clib/sound/alsa/constants_check.h:1.2 --- kaffe/libraries/clib/sound/alsa/constants_check.h:1.1 Wed Apr 28 20:42:58 2004 +++ kaffe/libraries/clib/sound/alsa/constants_check.hWed Jan 18 07:37:43 2006 @@ -136,8 +136,12 @@ assert(SND_SEQ_PRIORITY_HIGH == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_PRIORITY_HIGH); assert(SND_SEQ_PRIORITY_MASK == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_PRIORITY_MASK); assert(SND_SEQ_CLIENT_SYSTEM == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_CLIENT_SYSTEM); +#ifdef SND_SEQ_CLIENT_DUMMY assert(SND_SEQ_CLIENT_DUMMY == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_CLIENT_DUMMY); +#endif +#ifdef SND_SEQ_CLIENT_OSS assert(SND_SEQ_CLIENT_OSS == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_CLIENT_OSS); +#endif /* assert(SND_SEQ_FILTER_BROADCAST == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_FILTER_BROADCAST); */ /* assert(SND_SEQ_FILTER_MULTICAST == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_FILTER_MULTICAST); */ /* assert(SND_SEQ_FILTER_BOUNCE == org_tritonus_lowlevel_alsa_AlsaSeq_SND_SEQ_FILTER_BOUNCE); */ ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] New bugzilla for kaffe
Hi all, I am pleased to announce that Kaffe.org has now a functional bugzilla online. Now all kaffe bugs shoud go into this bugzilla except if they are classpath's related bugs and in that case the bugs will go into classpath's bug tracker. There is a detailed notice in the front page of the bugzilla to explain it. I have removed the bugs entry in the menu and replaced it by the bugzilla front page. For the moment the default assignement is such that nearly all bugs goes to me first (except the build bugs that I assign by default to dalibor). There is also a move bug in/out function in this bugzilla. I have yet to explore it to see how we could connect debian's bug database and ours. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] New bugzilla for kaffe
Hi, I have forgotten the essential ! :) To access bugzilla directly: http://www.kaffe.org/bugzilla/ Guilhem. Guilhem Lavaux wrote: Hi all, I am pleased to announce that Kaffe.org has now a functional bugzilla online. Now all kaffe bugs shoud go into this bugzilla except if they are classpath's related bugs and in that case the bugs will go into classpath's bug tracker. There is a detailed notice in the front page of the bugzilla to explain it. I have removed the bugs entry in the menu and replaced it by the bugzilla front page. For the moment the default assignement is such that nearly all bugs goes to me first (except the build bugs that I assign by default to dalibor). There is also a move bug in/out function in this bugzilla. I have yet to explore it to see how we could connect debian's bug database and ours. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] zlib.h checking with fastjar
Hi Kiyo, Paths are not right in Makefile.am (you can see -I../zlib/ but it should be -I$(srcdir)/../zlib/) . I think I have fixed it now. Could you try again ? Cheers, Guilhem. Kiyo Inaba wrote: Hi, Thanks to improve using fastjar for kaffe. After this introduction, yesterday is the first time for my regression test. And I noticed, one of my build environment does not have zlib.h installed. And of course configure script checks this as checking zlib.h usability... no checking zlib.h presence... no checking for zlib.h... no but, the build process continues and failed in compilation as make[4]: Entering directory `/proj/kaffe/kaffe-snap-060112-m68k-linux-i/external/gcc/fastjar' source='jartool.c' object='fastjar-jartool.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/sh ../../../../kaffe-snap-060112/external/gcc/fastjar/scripts/depcomp \ gcc -DHAVE_CONFIG_H -I. -I../../../../kaffe-snap-060112/external/gcc/fastjar -I. -I. -I../../../../kaffe-snap-060112/external/gcc/fastjar -I../zlib/ -I../../../../kaffe-snap-060112/external/gcc/fastjar/../include -DWITH_SHIFT_DOWN -W -Wall -pedantic -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -I../../../../kaffe-snap-060112/external/gcc/fastjar/../../../replace -I./../../../replace -g -O2 -Wall -W -O1 -fno-omit-frame-pointer -pthread -c -o fastjar-jartool.o `test -f 'jartool.c' || echo '../../../../kaffe-snap-060112/external/gcc/fastjar/'`jartool.c ../../../../kaffe-snap-060112/external/gcc/fastjar/jartool.c:195: zlib.h: No such file or directory make[4]: *** [fastjar-jartool.o] Error 1 make[4]: Leaving directory `/proj/kaffe/kaffe-snap-060112-m68k-linux-i/external/gcc/fastjar' Has it becomes mandatory to have zlib when we use fastjar? It looks like zlib.h (and other files) are in external/gcc/zlib, and possibly it can be used. Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] jthreads problem
Hi Ioannis, I am writing to you to say that I am really considering your problem. Actually the VM does look into a strange state where it eats all the CPU without going further anymore (though I am not sure yet at the moment I have to analyze the dynamic of what it is doing). I am experiencing the problem on both pthreads and jthreads. I will try to fix this asap. Give me something like one week to know what happens. I am really sorry to have missed your previous meesage in december but sometimes I parse the ML quite quickly. I keep you informed. Regards, Guilhem. Ioannis Liverezas wrote: Hi, In my previous post (http://www.kaffe.org/pipermail/kaffe/2005-December/103736.html), while working with an arm processor based system, I have found a bug in the threads system of kaffe-1.1.6. The bug exists in the combined use of Thread.interrupt() and Thread.sleep(). The bug also exists and is worse in the x86 architecture. After having tried the test many times in both architectures, (and with various VMs also), the results are: --- the x86 architecture demonstrates the problem very fast in about less than a minute. --- ARM based systems also fail to pass the test, but it may take from 5 minutes to one day to hang. In my previous post I have also included the source code of my test. Yesterday, 9/1/2006, while trying the cvs version on x86, after running the same test for half an hour, I took the following error: Thread: Time1000 :sync :1 Alive:09/01/2006, 18:48:06.567 Test started at 09/01/2006, 18:14:26.086 kaffe-bin: jthread.c:2452: jmutex_unlock: Assertion `tid-status != 1' failed. Aborted. The two first lines are printouts from my test program. In previous versions of kaffe, 1.1.6 or cvs, the test would hang with all threads sleeping. - iliverez ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixed class accessibility.
Ito Kazumitsu wrote: From: Ito Kazumitsu [EMAIL PROTECTED] Date: Thu, 22 Dec 2005 11:08:15 +0900 (JST) The runtime access control is much simpler than the compile-time access control. And we may be able to omit the checking of nested relations of classes at runtime. Simply omitting the checking of nested relations of classes causes IllegalAccessError, which was reported in November, 2003. I am afraid Sun's VM spec: A class or interface C is accessible to a class or interface D if and only if either of the following conditions are true: (Runtime): - C is public. - C and D are members of the same runtime package. is incomplete and something should be said about the case where C is protected. Attached below is my proposed patch. I have deleted the checking of outer classes for determining slot_acc, but kept such checking for determining class_acc. With this patch applied, - All the regression tests pass. - Mauve test gnu.testlet.java.lang.Class.newInstance shows the same results as Sun's JDK. - The testcase attached to http://www.kaffe.org/pipermail/kaffe/2003-November/096187.html passes. Hi Ito, Thanks for spending some more time in access.c. My previous patch was minimalist. But if this one passes everything it's great and please apply it to CVS ! I think we should add a regression test for this feature also. I will do it before release if you do not. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixed class accessibility.
Hi Ito,
I have met a new IllegalAccessError in eclipse. I have attached two
files which reproduce the problem.
The protected bit is difficult to handle apparently. I have talked with
Tom Tromey and it says that normally we should completely ignore the
accessibility flag in inner classes.
Regards,
Guilhem.
Ito Kazumitsu wrote:
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Thu, 22 Dec 2005 11:08:15 +0900 (JST)
The runtime access control is much simpler than the compile-time
access control. And we may be able to omit the checking of nested
relations of classes at runtime.
Simply omitting the checking of nested relations of classes
causes IllegalAccessError, which was reported in November, 2003.
I am afraid Sun's VM spec:
A class or interface C is accessible to a class or interface D if and only if
either of the following conditions are true:
(Runtime):
- C is public.
- C and D are members of the same runtime package.
is incomplete and something should be said about the case
where C is protected.
Attached below is my proposed patch. I have deleted the
checking of outer classes for determining slot_acc,
but kept such checking for determining class_acc.
With this patch applied,
- All the regression tests pass.
- Mauve test gnu.testlet.java.lang.Class.newInstance shows the
same results as Sun's JDK.
- The testcase attached to
http://www.kaffe.org/pipermail/kaffe/2003-November/096187.html
passes.
import a.*;
public class legal2
{
static public void main(String args[])
{
legal1.A a = legal1.getA();
System.out.println(a.b);
}
}
package a;
public class legal1
{
static protected class A
{
public int b;
}
static public A getA()
{
A a = new A();
a.b = 1;
return a;
}
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixed class accessibility.
Hi Ito,
Here is a better example. The previous could not be compiled directly if
you try to compile indepedently then you'll see the runtime accepts it.
Here I have an example which compiles and should run on a VM. However
kaffe throws an IllegalAccessError.
Regards,
Guilhem.
Ito Kazumitsu wrote:
From: Ito Kazumitsu [EMAIL PROTECTED]
Date: Thu, 22 Dec 2005 11:08:15 +0900 (JST)
The runtime access control is much simpler than the compile-time
access control. And we may be able to omit the checking of nested
relations of classes at runtime.
Simply omitting the checking of nested relations of classes
causes IllegalAccessError, which was reported in November, 2003.
I am afraid Sun's VM spec:
A class or interface C is accessible to a class or interface D if and only if
either of the following conditions are true:
(Runtime):
- C is public.
- C and D are members of the same runtime package.
is incomplete and something should be said about the case
where C is protected.
Attached below is my proposed patch. I have deleted the
checking of outer classes for determining slot_acc,
but kept such checking for determining class_acc.
With this patch applied,
- All the regression tests pass.
- Mauve test gnu.testlet.java.lang.Class.newInstance shows the
same results as Sun's JDK.
- The testcase attached to
http://www.kaffe.org/pipermail/kaffe/2003-November/096187.html
passes.
package a;
public class legal1
{
static protected class A
{
public int b;
}
static public A getA()
{
A a = new A();
a.b = 1;
return a;
}
}
import a.*;
public class legal2 extends legal1
{
static public void main(String args[])
{
final legal1.A a = legal1.getA();
Object o;
o = new Object() {
public String toString()
{
return (new Integer(a.b)).toString();
}
};
System.out.println(o);
}
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixed class accessibility.
Ito Kazumitsu wrote: Hi Guilhem, I have met a new IllegalAccessError in eclipse. I have attached two files which reproduce the problem. legal2.java did not compile. Found 1 semantic error compiling legal2.java: 7. legal1.A a = legal1.getA(); ^ *** Semantic Error: Type legal1$A was not found. So I moved legal2.java to a/legal2.java and changed import a.* to package a. Is it OK? Hi Ito, No. They must be in two separated packages. These java source files actually does not compile directly. The other ones I have sent compile but do not run. Guilhem. Yes, running legal2 causes IllegalAccessError. But after applying my patch, legal2 prints this: $ kaffe -classpath . a.legal2 1 The protected bit is difficult to handle apparently. I have talked with Tom Tromey and it says that normally we should completely ignore the accessibility flag in inner classes. We may as well do so to make things simple. Yes I will see what's possible to do in classMethod.c Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): More (and hopefully final) fixes for access.
Hi, After checking a few things here and there it appears that we are too strict. The VM must only rely on access flags of the class to check the accessibility. The inner class flags are used by the other compiler and the reflections. So we may remove everything related to inner/nested classes in access.c and take care of returning the right flags to the java library. I have checked: * gnu/testlet/java/lang/Class/newInstance and it works like the JDK * our regression tests (these two had to be updated because they were also not working on the JDK) * the test http://www.kaffe.org/pipermail/kaffe/2003-November/096187.html * my own test * eclipse. Regards, Guilhem. Kaffe CVS wrote: PatchSet 7032 Date: 2005/12/22 17:51:17 Author: guilhem Branch: HEAD Tag: (none) Log: More (and hopefully final) fixes for access. * kaffe/kaffevm/access.c (checkAccess): Simplified to the maximum according to Sun's VM spec we must not check for specific inner classes flags. * kaffe/kaffevm/classMethod.c (addInnerClasses): Do not merge inner class access flags with the class flags. * libraries/clib/native/Class.c (java_lang_VMClass_getModifiers): Return the right access flags depending on what we are asked and whether the class is nested. * test/regression/TestSerialFields.java, test/regression/TestSerialVersions.java: Removed private modifier to be able to run the tests (as for JDK). Members: ChangeLog:1.4551-1.4552 kaffe/kaffevm/access.c:1.15-1.16 kaffe/kaffevm/classMethod.c:1.149-1.150 libraries/clib/native/Class.c:1.86-1.87 test/regression/TestSerialFields.java:1.3-1.4 test/regression/TestSerialVersions.java:1.3-1.4 ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ecj-compiled kaffe fails in regression tests
Hi Ito, Ito Kazumitsu wrote: From: Ito Kazumitsu [EMAIL PROTECTED] Date: Fri, 09 Dec 2005 13:31:58 +0900 (JST) So the question is whether the assumption that returned test array is consistently sorted is valid or not. If the assumption is valid, then ecj may be wrong. Otherwise we will have to modify the test programs so that it can check the result without depending on the order of array elements. Sun's API document of getDeclaredClasses says nothing about the order of elements in the returned array. So I do not tink it is a good thing to write a program which assumes some special order of elements of the array. So I think Kaffe's TestSerial*.java should be modified. Many thanks for exploring the reason of the bug. :) I am modifying the tests to sort the classes before running the test. However while comparing kaffe's output to sun's jdk I got some annoying differences in the way some exception are thrown. So these tests will remain as broken while someone fixes it (I'll try to do it...) Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ecj-compiled kaffe fails in regression tests
Hi Wolfgang, I'll check in a patch for that tonight... I have also noticed that ecj was causing some troubles to kaffe and I'll remedy to them a bit later. Regards, Guilhem. Wolfgang Baer wrote: Hi Ito, Ito Kazumitsu wrote: Using the following poor man's ecj, $ cat bin/ecj #!/bin/sh exec /usr/local/kaffe/bin/kaffe \ -classpath $HOME/javalib/org.eclipse.jdt.core_3.1.1.jar \ org.eclipse.jdt.internal.compiler.batch.Main \ $@ I could make kaffe from kaffe-snapshot-20051206.tar.gz from http://people.debian.org/~avdyk/kaffe/snapshot/. After manually editing some script files, I managed to run make check, but the results were Would you mind to post the patch for your editing of these scripts? This is the last remaining problem before we can switching the debian kaffe package to ecj - currently we cannot run the regression checks. Regards, Wolfgang ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fix to be able to use ECJ instead of JIKES.
Hi Wolfgang, Wolfgang Baer wrote: Hi Guilhem, Kaffe CVS wrote: PatchSet 6980 Date: 2005/12/03 12:54:16 Author: guilhem Branch: HEAD Tag: (none) Log: Fix to be able to use ECJ instead of JIKES. * configure.ac: Added a new option --with-ecj to be able to compile with ecj. Reworked the java compiler detection. This makes compilation with ecj easier for packagers - thanks. I just tried it, the normal kaffe compilation succeeds. However the testsuite still doesn't compile with ecj so we don't get testresults. Attached the testresult part of the build log. The other big problem from the distribution point of view (we want to switch away from jikes) is the already mentioned problem that you cannot use ecj to compile java sources with kaffe currently. Yes. It is an issue I am going to solve soon (today or tomorrow). It's a problem of compatibility vs jdk's files and directories. I have to change some defaults and see if it improves this. Concerning the other problem with regression tests it is partly ecj's fault. It doesn't accept classpaths beginning with ':', though it may accept them inside the classpath. I mean: * CLASSPATH=:somejar:somedirectory is illegal for ecj * CLASSPATH=somejar::somedirectory is legal for ecj I will see if I can circumvent this bug. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fix to be able to use ECJ instead of JIKES.
Ito Kazumitsu wrote: From: Kaffe CVS [EMAIL PROTECTED] Date: Sat, 03 Dec 2005 05:04:09 -0800 Fix to be able to use ECJ instead of JIKES. Being an old-fashined programmer, I am not interested in Eclipse, but would like to try ECJ because JIKES seems to be inactive now. Unfortunately, I can not find out where I can get ECJ. Is ECJ equivalent to java -jar org.eclipse.jdt.core_3.1.1.jar? Isn't it stupid to get 100MB of Eclipse to use 3MB of JDT core? Hi Ito, Yes ECJ is this jar. It is fully usable without the rest of eclipse package so just forget about the other jar and keep this one. There is a distribution of ecj itself in the debian repository (ecj-bootstrap). Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe and ecj
Hi Wolfgang,
It looks like ecj/ant discover the bootclasspath automatically
somewhere. However with the integration of GNU Classpath the runtime jar
is now called glibj.zip (maybe we should change this). Ant does not
discover this and produce a wrong bootclasspath/classpath. As a
consequence ecj is not able to see java.lang.Object. I am thinking about
a workaround...
Regards,
Guilhem.
Wolfgang Baer wrote:
Hi all,
kaffe does not work with ecj used with ant for compilation.
Putting ecj.jar into the normal classpath results in the following:
[EMAIL PROTECTED]:~/kaffe_ecj_test$ JAVA_HOME=/usr/lib/kaffe ant -lib
/usr/share/java/ecj.jar
Buildfile: build.xml
compile:
[javac] Compiling 1 source file
[javac] --
[javac] 1. ERROR in /home/wbaer/kaffe_ecj_test/Test.java
[javac] (at line 1)
[javac]
[javac] public class Test {
[javac] ^
[javac] The type java.lang.Object cannot be resolved. It is
indirectly referenced from required .class files
[javac] --
[javac] 1 problem (1 error)
BUILD FAILED
/home/wbaer/kaffe_ecj_test/build.xml:3: Compile failed; see the compiler
error output for details.
The needed build.compiler property is already set internal in
VMSystemProperties.java to org.eclipse.jdt.core.JDTCompilerAdapter.
Steps to reproduce:
Put the attached files in one directory and use the above command or with
-Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter if not set
internal.
Regards,
Wolfgang
public class Test {
}
project basedir=. default=compile
target name=compile
javac srcdir=${basedir} /
/target
/project
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] PROBLEM WITH INITTHREADS-FUNCTION
Hi Daniel, If you don't have enough memory then the VM should tell you explicitly. In that case I expect it is more a bug in the trampolines of kaffe. 16MB of ram should be sufficient for the minimal usage of kaffe (we had reports that we need approximately 5MB at minimum to load GNU Classpath). You can join us on #kaffe (irc.freenode.net). We made experiments on m68k but I don't exactly remember the state. Regards, Guilhem. [EMAIL PROTECTED] wrote: Hello list! A have following question: i have ported kaffe-1.0.7 to an embedded system board Coldfire m68k 5282 with eCos as os. This board has 8 MB Flash and 16 MB RAM. When running kaffe, i get following error: NegativeArraySizeException at Threadgroup.java at line 84. IS IS POSSIBLE THAT MY COLDFIRE BOARD HAS NOT ENOUGH RAM FOR HEAP ALLOCATION? What are the minimum hardware requirements for running kaffe? I get the error in the initialise()-routine in the initThreads function in the callMethodV(). Has anyone an idea? Thanks for anwering, Dani ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] problems with thread and ServerSocket.close()
Hi Jean-Frederic, The problem should be fixed now in CVS. I have tested your program locally with kaffe and it seems to work now. Please tell me if you are still experiencing some troubles... Regards, Guilhem. Jean-frederic Clere wrote: Hi, I have tried a small test program that runs correctly in Sun JVM but hangs in kaffe: By close() on a ServerSocket I expect to cause an exception in the thread where I am doing the accept() om the same ServerSocket, but the close() hangs until a new connection is openned. Any hints why the close() does not provoque an exception in the accept(). Cheers Jean-Frederic PS: Find attached the java code I am using. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] initial frame position
Gianluca Moro wrote:
hi all,
I'm running kagge with a graphical output
directly on X, without any window manager.
I see that all the applicatio I start are placed in (0,0)
(upper lefr corner of the screen) while starting
my java application under kaffe it is placed in a bit
on the left, and below the upper screen (about (5,30)).
I think that you are using kaffe-x-awt AWT ? Then there is an heuristic
algorithm to detect the size of the decoration which is applied to a
frame. In the case there is no WM maybe it is wrong. However it is
possible to disengage the heuristic by removing the property
EXTERNAL_DECO in libraries/clib/awt/X/tlk.c:tlkProperties().
Could you try this ?
Thanks,
Regards,
Guilhem.
I imagine this is some default setted in kaffe or in the
java interface: is there an option to force
the position in (0,0), osmething analogous to
give -geometry +0+0?
(My test:
#
LD_PRELOAD=/usr/X11R6/lib/libX11.so:/usr/lib/libpng.so:/usr/lib/libz.so:/usr/local/lib/libjpeg.so
/usr/local/kaffe/bin/kaffe -geometry +0+0 -Dkaffe.awt.nativelib=xawt
-Xbootclasspath/p:/usr/local/kaffe/kaffeawt.jar Jnoti
gives:
java.lang.ClassNotFoundException: +0+0 not found in
java.lang.ClassLoader$1{urls=[file:/etc/init.d/./], parent=null}
thanks
giammy
--
Gianluca Moro http://groups.yahoo.com/group/embeddeditalia/
ISCRIVITI alla Mailing List Italiana su LINUX EMBEDDED
[EMAIL PROTECTED] Visit http://ilpinguino.altervista.org/
___
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Bug Report - Kaffe with AntiVir
Marko Merl wrote: hey, today i installed antivir-workstation-6.32.0.56-linux. it runs perfactly in the console but if i start the gui (antivir-gui) i got this error-message: --- ERROR --- kaffe-bin: /build/buildd/kaffe-1.1.6/build-tree/kaffe-1.1.6/kaffe/kaffevm/support.c:351: lookupClassMethod: Assertion `cls != ((void *)0)' failed. --- EOF --- so, what can i do to get this error away? Could you try the CVS head version ? :) Generally bugs are already fixed here. If it is not the case we will have to enter a debugging session. ;) Thanks, Regards, Guilhem. thanks for your help forward. see you, --- Marko Merl http://www.linux-tux.at ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Question about function 'sysdepCallMethod'
Hi, sysdepCallMethod is not simply this. It ensures that the arguments are passed correctly according to the ABI for some architecture/os/compiler combination. Generally it must be written in assembly or using some tricks of the compiler. sysdepCallMethod takes a pointer to some function, its arguments and then build a function call and finally call it. Once the function returns, the returned value is taken from the stack/registers and pushed into the return value memory. Regards, Guilhem. qi fenghai wrote: Hi all, Please advise if 'sysdepCallMethod' can be implemented by this way as bellow: method 1: in JVM: typedef int (*FUNCTYPE)(); //function's return type is int FUNCTYPE *nativefunc = (FUNCTYPE)dlsym(handle, foo); //four argument (*nativefunc)(1, 2.5); in share library: int foo(int, double); method 2: in JVM: typedef int (*FUNCTYPE)(...); //function's return type is int, argument list is '...' FUNCTYPE *nativefunc = (FUNCTYPE)dlsym(handle, foo); //four argument (*nativefunc)(1, 2.5); in share library: int foo(int, double); _ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] classpath _merged_
Ito Kazumitsu wrote: Hi, From: Guilhem Lavaux [EMAIL PROTECTED] Date: Wed, 19 Oct 2005 22:55:35 +0200 The classpath tree has been merged. I know that it builds, runs regression tests install peacefully here but I haven't yet tested make dist. If there are problems they will be fixed progressively. In my case, it did not build. configure: error: cannot run /usr/local/bin/bash ./config.sub configure: error: /usr/local/bin/bash './configure' failed for libraries/javalib/external/classpath Hi, Thanks Ito. Fixed in CVS now. BTW, I am going also to merge back some files to classpath's CVS and then we'll be able to copy a new snapshot from classpath's CVS. Cheers, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (kaz): libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java,
Hi Ito,
Could you push your patch yourself on classpath-patches ml ? :) I could
do it but it is maybe better if you do it.
Thanks for bringing it back btw !
Guilhem.
Kaffe CVS wrote:
PatchSet 6951
Date: 2005/10/20 14:59:56
Author: kaz
Branch: HEAD
Tag: (none)
Log:
2005-10-20 Ito Kazumitsu [EMAIL PROTECTED]
*
libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java,
libraries/javalib/external/classpath/gnu/java/nio/charset/UnicodeLittle.java,
libraries/javalib/external/classpath/gnu/java/nio/charset/iconv/IconvProvider.java:
Proposed patch for GCC Bugzilla Bug 23008 and 22968.
Members:
ChangeLog:1.4475-1.4476
libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java:1.1-1.2
libraries/javalib/external/classpath/gnu/java/nio/charset/UnicodeLittle.java:1.1-1.2
libraries/javalib/external/classpath/gnu/java/nio/charset/iconv/IconvProvider.java:1.1-1.2
Index: kaffe/ChangeLog
diff -u kaffe/ChangeLog:1.4475 kaffe/ChangeLog:1.4476
--- kaffe/ChangeLog:1.4475 Wed Oct 19 20:48:10 2005
+++ kaffe/ChangeLog Thu Oct 20 14:59:56 2005
@@ -1,3 +1,10 @@
+2005-10-20 Ito Kazumitsu [EMAIL PROTECTED]
+
+ *
libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java,
+
libraries/javalib/external/classpath/gnu/java/nio/charset/UnicodeLittle.java,
+
libraries/javalib/external/classpath/gnu/java/nio/charset/iconv/IconvProvider.java:
+ Proposed patch for GCC Bugzilla Bug 23008 and 22968.
+
2005-10-19 Guilhem Lavaux [EMAIL PROTECTED]
* developers/update-vm-list: New script adapted from update-class-list
Index:
kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java
diff -u
kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java:1.1
kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java:1.2
---
kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java:1.1
Wed Oct 19 20:36:31 2005
+++
kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java
Thu Oct 20 15:00:03 2005
@@ -54,6 +54,8 @@
static final int BIG_ENDIAN = 0;
static final int LITTLE_ENDIAN = 1;
static final int UNKNOWN_ENDIAN = 2;
+ static final int MAYBE_BIG_ENDIAN = 3;
+ static final int MAYBE_LITTLE_ENDIAN = 4;
private static final char BYTE_ORDER_MARK = 0xFEFF;
private static final char REVERSED_BYTE_ORDER_MARK = 0xFFFE;
@@ -81,26 +83,37 @@
byte b2 = in.get ();
// handle byte order mark
-if (byteOrder == UNKNOWN_ENDIAN)
+if (byteOrder == UNKNOWN_ENDIAN ||
+byteOrder == MAYBE_BIG_ENDIAN ||
+byteOrder == MAYBE_LITTLE_ENDIAN)
{
char c = (char) (((b1 0xFF) 8) | (b2 0xFF));
if (c == BYTE_ORDER_MARK)
{
+if (byteOrder == MAYBE_LITTLE_ENDIAN)
+ {
+return CoderResult.malformedForLength (2);
+ }
byteOrder = BIG_ENDIAN;
inPos += 2;
continue;
}
else if (c == REVERSED_BYTE_ORDER_MARK)
{
+if (byteOrder == MAYBE_BIG_ENDIAN)
+ {
+return CoderResult.malformedForLength (2);
+ }
byteOrder = LITTLE_ENDIAN;
inPos += 2;
continue;
}
else
{
-// assume big endian, do not consume bytes,
+// assume big or little endian, do not consume bytes,
// continue with normal processing
-byteOrder = BIG_ENDIAN;
+byteOrder = (byteOrder == MAYBE_LITTLE_ENDIAN ?
+ LITTLE_ENDIAN : BIG_ENDIAN);
}
}
Index: kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/UnicodeLittle.java
diff -u
kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/UnicodeLittle.java:1.1
kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/UnicodeLittle.java:1.2
---
kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/UnicodeLittle.java:1.1
Wed Oct 19 20:36:31 2005
+++
kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/UnicodeLittle.java
Thu Oct 20 15:00:03 2005
@@ -64,7 +64,7 @@
public CharsetDecoder newDecoder ()
{
-return new UTF_16Decoder (this, UTF_16Decoder.UNKNOWN_ENDIAN);
+return new UTF_16Decoder (this, UTF_16Decoder.MAYBE_LITTLE_ENDIAN);
}
public CharsetEncoder newEncoder ()
Index:
kaffe/libraries/javalib/external/classpath/gnu/java/nio/charset/iconv/IconvProvider.java
diff -u
kaffe/libraries/javalib
Re: [kaffe] CVS kaffe (kaz): libraries/javalib/external/classpath/gnu/java/nio/charset/UTF_16Decoder.java,
Ito Kazumitsu wrote: Hi, From: Guilhem Lavaux [EMAIL PROTECTED] Date: Thu, 20 Oct 2005 20:59:38 +0200 Could you push your patch yourself on classpath-patches ml ? :) I could do it but it is maybe better if you do it. I reported the bugs and submitted the patches to Savannah last June, and the bugs are still open. Which is the right place to submit patchs? classpath-patches? commit-classpath? Or the bug reporting web site? I think that when you are not a developper it's better to submit them to the web site. In your case I don't remember whether you have the access rights to the CVS. If it's so then you can send your patches to classpath-patches and after a review check it in into the CVS. If not I'll do it. Cheers, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Classpath merge
Dalibor Topic wrote:
Guilhem Lavaux wrote:
Hi,
Salut Guilhem,
As some people know I have nearly finished merging the classpath tree
into kaffe tree. There are still a couple of issues to solve with
installing classpath libraries into the right places and how to deal
with glibj.zip (build it ourself or make classpath build system build
it). The problem is that classpath's configure is not really
configurable on the place where to put the libraries. Especially it is
not possible at the moment to force it to use ${prefix}/jre/lib/${cpu}
for the native libraries and ${prefix}/jre/lib/rt.jar for the java
library.
Would it be possible to use $(LN_S) for the additional install step
after the classpath build system is done with its own thing? Another
option could be setting DESTDIR in install-local target of the invoking
Makefile.am.
I am considering modifying a bit more classpath's configure so
we can do that in future. So expect the merge to happen this week. I'll
send a warning message just before because the tree is very altered.
Great! Thanks a lot for doing this work.
Ok. It installs the file at the right place but not the right name. I am
going to push the new tree in CVS now. So no commit for the moment. :)
Cheers,
Guilhem.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] classpath _merged_
Hi, The classpath tree has been merged. I know that it builds, runs regression tests install peacefully here but I haven't yet tested make dist. If there are problems they will be fixed progressively. Cheers, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] problem with guis
Hi Marcus, Thanks for the bug report. As we still don't have a bug database it is a bit difficult to track them sometimes. So thanks again for reminding us about that fact. I'll check if I can reproduce the bug (in that case I'll fix it asap) if not I'll ask you to do a few things. ATM, I am a bit busy merging classpath and other things so I cannot deal with it (I'll be able in a few days). Cheers, Guilhem. Marcus Wu wrote: I seem to be having a problem launching applications with guis in them. I am attempting to use middlegen, but keep getting an assertion failing in lookupClassMethod: -Cut--- middlegen-2.1/samples# ant hsqldb-gui Buildfile: build.xml hsqldb-gui: [java] kaffe-bin: /build/buildd/kaffe-1.1.6/build-tree/kaffe-1.1.6/kaffe/kaffevm/support.c:351: lookupClassMethod: Assertion `cls != ((void *)0)' failed. BUILD FAILED middlegen-2.1/samples/build.xml:800: Java returned: -6 Total time: 12 seconds -Cut--- If I build/run other targets without guis they work. In a thread in Sept 2005(http://www.kaffe.org/pipermail/kaffe/2005-September/103343.html), someone asked about a simliar issue. It was labeled as a bug in 1.1.6. Is there any known workaround/patch/fix for this? - Marcus Wu [EMAIL PROTECTED] ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] sigcontext/siginfo problem under netbsd
Antoine Reilles wrote: Hi, There is a bug report in the netbsd bug tracker about the use of sigcontext in the pthreads code of kaffe. http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=30585 The bug report and the proposed patches are for kaffe-1.1.5, but they are propably relevant for 1.1.6 too Regards, antoine ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe Hi Antoine, Yes. The answers are exact and the fix has been commited a long time ago now. I should have answered to the PR. Kaffe 1.1.6 should work on netbsd if I remember correctly. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Status of boehm-gc vs. kaffe-gc?
Hi Gwenole, I have just fixed an important bug in the GC on AMD64. GC was freeing used memory on it and now the stack is walked correctly. However, I have noticed there is still SMP oddities sometimes. Cheers, Guilhem Lavaux. Gwenole Beauchesne wrote: Hi, Dalibor told me you'd know more precisely the status of boehm-gc vs. kaffe-gc. I am asking because on x86_64 (gcc 4.0-branch, glibc 2.3.5), I sometimes get failures in the testsuite where all threads are waiting for something. This is with the default kaffe-gc. What's more, this cannot be repeatedly reproduced, unfortunately. i.e. on next runs, the tests can pass. With boehm-gc, all tests but one (ClassGC) pass on x86_64. This one either fails with a hang (all threads blocked) or an assert() failure, etc. I believe there are some 64-bit bugs left in the common GC parts. FWIW, the latest Kaffe that passed all tests on x86_64 was 1.1.4. BTW, I also merged from GCC 4.0.2 boehm-gc for testing with no improvement. Anyone with another 64-bit platform to compare results? Debugging that with gdb is somewhat head-scratching stuff and I have yet to find out the root cause. If anyone has an idea, he is welcome. Thanks, Gwenolé. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: Status of boehm-gc vs. kaffe-gc?
Gwenole Beauchesne wrote: Hi, Dalibor told me you'd know more precisely the status of boehm-gc vs. kaffe-gc. I am asking because on x86_64 (gcc 4.0-branch, glibc 2.3.5), I sometimes get failures in the testsuite where all threads are waiting for something. This is with the default kaffe-gc. What's more, this cannot be repeatedly reproduced, unfortunately. i.e. on next runs, the tests can pass. I have tested kaffe HEAD on a SMP opteron and it always fails though not exactly in the same way. There are loads of null pointer exception and memory inconsistencies. The stack looks like a bit screwed but I don't have yet details. I'll take some time this week/week end for this problem as it is really important. I don't think it is GC related though it is more there is an asumption somewhere that sizeof(void *) == sizeof(int). With boehm-gc, all tests but one (ClassGC) pass on x86_64. This one either fails with a hang (all threads blocked) or an assert() failure, etc. I believe there are some 64-bit bugs left in the common GC parts. FWIW, the latest Kaffe that passed all tests on x86_64 was 1.1.4. BTW, I also merged from GCC 4.0.2 boehm-gc for testing with no improvement. boehm-gc interface is still a bit unstable principally due to the object lifecycle which is different from kaffe-gc. In kaffe-gc objects are triggered for finalization and then destroyed (and there are two separate events for that). In boehm-gc you only have a finalization event and I need to emulate the other one. I have nearly managed to do it but some bugs are still resisting. I would like to find some time to fix them but not so much at the moment for this task. Anyone with another 64-bit platform to compare results? Debugging that with gdb is somewhat head-scratching stuff and I have yet to find out the root cause. If anyone has an idea, he is welcome. Thanks, Gwenolé. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixlet for Security
On Mon, 2005-08-15 at 20:34 +0200, mag wrote: Hi! I guess a warning about not finding good random source would be suitable here. It would be a pity to appear on bugtraq because this. Or did I misunderstood something? I may print a warning on LameRandomness construction which is the default constructor in the case UnixRandomness is not available. The default implementation uses java.util.Random which is obviously of less quality than urandom. However this may confuse some application which would not expect this message. So I suggest to have a quiet property to be able to shut it down just in case. Regards, Guilhem. 2005-08-15, h keltezéssel 08.44-kor Kaffe CVS ezt írta: PatchSet 6830 Date: 2005/08/15 15:36:08 Author: guilhem Branch: HEAD Tag: (none) Log: Fixlet for Security 2005-08-15 Guilhem Lavaux [EMAIL PROTECTED] * libraries/javalib/kaffe/security/providers/SHA1PRNG.java (clinit): Catch any remaining exception. This fixes a problem with SecureRandomTest not finding /dev/urandom on some system. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Apache Jakarta Commons Net does not work on Linux
Hi Ito,
Two things:
* Commons-Net is flawed.
* Kaffe is flawed.
:)
First kaffe: I know that from the transvirtual times we have inherited a
synchronized access to native socket operations. That way we are sure
two threads are not accessing the same socket at the same time. However
it is not compatible with what is done by commons-net (and I think the
JDK)
Second commons-net: It should not access the same socket with two
threads. Looking at the code, the reader thread hangs in read() and then
can call write() from another thread. I am not sure it is really allowed
from the OS point of view and generally I would not advise it.
So now, what to do ? I will check whether the IO operations are
reentrant and then will move the mutexes.
Btw, I haven't got the assert error you mentioned. It should be a
problem in the libc itself as I am not tweaking the mutexes but on the
contrary raising protections around them. (What is Linux
2.6.7-co-0.6.2 ?)
Regards,
Guilhem.
On Wed, 2005-08-03 at 23:46 +0900, Ito Kazumitsu wrote:
From: Ito Kazumitsu [EMAIL PROTECTED]
Subject: [kaffe] Apache Jakarta Commons Net does not work on Linux
Date: Tue, 02 Aug 2005 00:10:49 +0900 (JST)
I have found that apache Jakarta Commons Net does not work
with current Kaffe on Linux.
I slightly changed the test program to find the following.
(1) Telnet client including FTP client of Apache Commons Net
performs its socket input operation in a different thread
called reader thread.
(2) When run on Kaffe on Linux, there seems to occur a deadlock
between the reader thread and the current thread. The writing
operation of the current thread cannot be finished until some
state of the reader thread changes. But the reading thread is
waiting for a response from the server, which will never come
until the writing operation of the current thread is finished.
(3) Such deadlock does not occur when run on Sun's JDK
or on Kaffe on FreeBSD.
(4) By setting some socket timeout value, the deadlock of (2)
can be releasd. But such timeout means the death of the reading
thread and this cannot be a solusion of the problem.
And on Linux 2.6.7-co-0.6.2, setting a timeout causes another
error like
$ java TestCommonsNet somehost foo bar 5000 true
220
kaffe-bin: pthread_mutex_lock.c:78: __pthread_mutex_lock: Assertion
`mutex-__data.__owner == 0' failed.
Aborted
(5) Telnet client including FTP client of Apache Commons Net has
an option of disabling the use of reader thread. This helps
to avoid the deadlock of (2).
Application system users can be satisfied with (5), but the problem
(2) seen only on Kaffe on Linux indicates some bugs in Kaffe.
My test program follows.
import org.apache.commons.net.ftp.*;
public class TestCommonsNet {
public static void main(String[] args) throws Exception {
String hostName = args[0];
int port = 21;
String userName = args[1];
String password = args[2];
int timeout = Integer.parseInt(args[3]);
boolean readerThread = (args[4].equals(true));
FTPClient _ftpClient = new FTPClient();
_ftpClient.setDefaultTimeout(timeout);
_ftpClient.setReaderThread(readerThread);
_ftpClient.connect(hostName, port);
System.err.println(_ftpClient.getReplyCode());
_ftpClient.login(userName, password);
System.err.flush();
System.err.println(_ftpClient.getReplyCode());
_ftpClient.logout();
System.err.println(_ftpClient.getReplyCode());
}
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] SecureRandomTest failed
Hi,
Ok. The old native code was checking the error code use more basic
functions if ioctl was failing. The TARGET_* layer is just using one way
to test things. I don't know if I must curse it or bless it. Grmbl..
Let's wait for Dalibor's patch and then we'll fix that.
Thank you very much Ito !
Regards,
Guilhem Lavaux.
On Mon, 2005-07-25 at 11:39 +0900, Ito Kazumitsu wrote:
From: Ito Kazumitsu [EMAIL PROTECTED]
Subject: Re: [kaffe] SecureRandomTest failed
Date: Sun, 24 Jul 2005 08:18:31 +0900 (JST)
java.io.IOException: Inappropriate ioctl for device
I am afraid that on FreeBSD, ioctl with FIONREAD cannot
be used for file IO.
The following simple program shows errno == 25 (Inappropriate ioctl
for device).
#include sys/ioctl.h
#include sys/filio.h
#include errno.h
#include fcntl.h
int main(int argc, char* argv) {
int n;
int fd;
fd = open(test.c, O_RDONLY);
int rc = ioctl(fd,FIONREAD,n);
printf(%d, %d\n, rc, errno);
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] SecureRandomTest failed
Hi Ito,
Thanks for the analysis. Actually with your second report I have feared
that the providers in java.security were not loaded. It apparently is
the case as you have reported. It would be interesting if you have some
time for this to check what happens in java.security.Security.clinit
and loadProviders. I know that some exceptions are hidden there and
these functions are in charge of loading the providers.
Thanks !
Regards,
Guilhem Lavaux.
On Sat, 2005-07-23 at 07:13 +0900, Ito Kazumitsu wrote:
I am afraid something has changed so that Security.getProviders() returns
gnu.java.security.provider.Gnu: name=GNU version=1.0
before
kaffe.security.provider.Kaffe: name=KAFFE version=1.0
Yes, gnu.java.security.provider.Gnu comes first. But that depends
on the environment.
I have found two independent problems related to this issue.
(1) In some environment, e.g. my case with FreeBSD 5.4-RELEASE,
Security.getProviders() by default lists only
gnu.java.security.provider.Gnu. So if you add
kaffe.security.provider.Kaffe, it is listed after
gnu.java.security.provider.Gnu.
But in another environment, Security.getProviders() by default lists
gnu.crypto.jce.GnuCrypto
org.metastatic.jessie.provider.Jessie
kaffe.security.provider.Kaffe
gnu.java.security.provider.Gnu
in this order. So if you add kaffe.security.provider.Kaffe,
it is not added because it is already there.
Older Kaffe on FreeBSD 5.4-RELEASE also behaved this way.
(2) The SHA1PRNG algorithm provided by gnu.java.security.provider.Gnu
is not secure enough because differnt instances always produce the
same result. So in an environment where the problem (1) exists,
SecureRandomTest fails.
To study this problem, I patched SecureRandomTest.java for debuging.
--- SecureRandomTest.java.origThu Feb 24 23:42:08 2005
+++ SecureRandomTest.java Sat Jul 23 05:52:43 2005
@@ -64,6 +64,10 @@
byte data[];
Security.addProvider(new kaffe.security.provider.Kaffe());
+ Provider[] pp = Security.getProviders();
+ for (int i=0; i pp.length; i++) {
+ System.err.println(pp[i]);
+ }
/*
* Make sure the SecureRandom's produce different sequences after
Then I tested this program on FreeBSD 5.4-RELEASE and Linux 2.6.7-co-0.6.2.
In both cases, I used kaffe whose ChangeLog head is:
2005-07-22 Guilhem Lavaux [EMAIL PROTECTED]
On FreeBSD 5.4-RELEASE:
[EMAIL PROTECTED] kaffe SecureRandomTest
gnu.java.security.provider.Gnu: name=GNU version=1.0
kaffe.security.provider.Kaffe: name=KAFFE version=1.0
java.lang.Error: The secure random isn't! : lpc= 0 lpc2 = 20 data =
8bc7ec02ec7c04f87a13ec6120616ead831baeaf
at java.lang.VMThrowable.fillInStackTrace (VMThrowable.java:native)
at java.lang.VMThrowable.fillInStackTrace (VMThrowable.java:79)
at java.lang.Throwable.fillInStackTrace (Throwable.java:498)
at java.lang.Throwable.init (Throwable.java:159)
at java.lang.Error.init (Error.java:81)
at SecureRandomTest.checkHistory (SecureRandomTest.java:51)
at SecureRandomTest.main (SecureRandomTest.java:89)
On Linux 2.6.7-co-0.6.2:
[EMAIL PROTECTED] kaffe SecureRandomTest
gnu.crypto.jce.GnuCrypto: name=GNU-CRYPTO version=2.1
org.metastatic.jessie.provider.Jessie: name=Jessie version=1.0
kaffe.security.provider.Kaffe: name=KAFFE version=1.0
gnu.java.security.provider.Gnu: name=GNU version=1.0
Two SecureRandoms produce different output.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] bug: jar -t/-x does't handle paths correctly
Hi, The patch looks ok to me. I will check it in reality just in case and commit it. Many thanks ! Regards, Guilhem. On Tue, 2005-07-19 at 14:41 -0400, Kurt Miller wrote: From: Kurt Miller [EMAIL PROTECTED] When jar is passed a path as a parameter using -t or -x, it doesn't recurse into the directory and list/extract the files and directories under it. For example: given a test jar that looks like this: $ jar tf test.jar META-INF/ META-INF/MANIFEST.MF com/ com/intricatesoft/ com/intricatesoft/test.class $ jar tf test.jar com lists nothing. jar xf com extracts nothing too. This is with 1.1.5. I have tried 1.1.5 with libraries/javalib/kaffe/tools/jar/Jar.java patched to match the HEAD version too. The below patch to HEAD adds support to jar to handle paths as described above. Paths ending in / and not ending in / are handled. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] kaffeh and inner classes
Hi,
Thank you very much for your patch ! We are sometimes a bit low to
answer and sorry for that. I will try it and if it looks ok it will go
into CVS.
Regards,
Guilhem Lavaux.
On Fri, 2005-07-15 at 17:07 -0400, Kurt Miller wrote:
From: Kurt Miller [EMAIL PROTECTED]
can kaffeh be used on inner classes?
It seems like it doesn't deal with the $ character correctly
and interprets it as a path separator.
Here's a patch that deals with the $ for inner classes.
The class name too long check looks arbitrary to me.
Not really sure where 100 comes from.
--- kaffe/kaffeh/main.c.orig Mon May 3 01:53:27 2004
+++ kaffe/kaffeh/main.c Fri Jul 15 17:40:44 2005
@@ -60,7 +60,7 @@
main(int argc, char* argv[])
{
char* nm;
- int i, first = 1;
+ int i, j, first = 1;
int farg;
/* Process arguments */
@@ -88,28 +88,37 @@
for (nm = argv[farg]; nm != 0; nm = argv[++farg]) {
/* Derive various names from class name */
- for (i = 0; nm[i] != 0; i++) {
- if (i = BUFSZ - 100) {
+ for (i = j = 0; nm[i] != 0; i++, j++) {
+ if (i = BUFSZ - 100 || j = BUFSZ - 105) {
dprintf(
kaffeh: class name too long\n);
exit(1);
}
switch (nm[i]) {
case '/':
- case '$':
case '.':
- className[i] = '_';
+ className[j] = '_';
pathName[i] = '/';
includeName[i] = '_';
break;
+ case '$':
+ className[j++] = '_';
+ className[j++] = '0';
+ className[j++] = '0';
+ className[j++] = '0';
+ className[j++] = '2';
+ className[j] = '4';
+ pathName[i] = nm[i];
+ includeName[i] = '_';
+ break;
default:
- className[i] = nm[i];
+ className[j] = nm[i];
pathName[i] = nm[i];
includeName[i] = nm[i];
break;
}
}
- className[i] = 0;
+ className[j] = 0;
pathName[i] = 0;
includeName[i] = 0;
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] nb1.6 build fail
Hi Kiyo, I've updated CVS once again to use old sigcontext structure if no sys/ucontext.h is found. I have tested it on qemu/netbsd 1.6/x86 and it was working without a failure. Cheers, Guilhem. On Mon, 2005-07-11 at 20:35 +0900, Kiyo Inaba wrote: Hi Guilhem, Thanks. I've missed that in Riccardo's patch. Could you try again CVS head now ? Unfortunately, it is not enough. Since I use jthread, and jthread.c contains ucontext_t as ../../../../../kaffe-snap-050707/kaffe/kaffevm/systems/unix-jthreads/jthread.c:157: parse error before `ucontext_t' Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] nb1.6 build fail
Hi Kiyo, Thanks. I've missed that in Riccardo's patch. Could you try again CVS head now ? Guilhem. On Sun, 2005-07-10 at 09:10 +0900, Kiyo Inaba wrote: Latest snap failed to be compiled on NetBSD 1.6 (ia32). Error log said, In file included from ../../config/md.h:1, from ../../../kaffe-snap-050707/kaffe/kaffeh/../kaffevm/classMethod.h:18, from ../../../kaffe-snap-050707/kaffe/kaffeh/support.c:26: ../../config/../../kaffe-snap-050707/config/i386/netbsd1/md.h:35: sys/ucontext.h: No such file or directory gmake[1]: *** [kaffeh-support.o] Error 1 Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Implementing NewWeakGlobalRef
Hi, We are only missing two functions in our JNI 1.4 implementation: NewWeakGlobalRef and DeleteWeakGlobalRef. These are intended as lightweight weak global reference builders in the VM. They create weak object reference from any object reference. From the documentation, it looks the weak reference are normal objects. My first impression is that to build a weak reference we have to hide the real object reference in a fixed allocated memory which will not be walked by the GC. However doing this we cannot use this reference as a good parameter for all other JNI functions. So, I am proposing to add an unvailing macro which will detect and decode weak reference. This macro should be called in all functions and on all parameters that represent object references (except array entries I think). This will however add some cost to each JNI call but I don't yet see how to implement it another cheap way. Any other idea ? Cheers, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] netbsd/ppc endianness problems
On Sat, 2005-06-25 at 11:36 +, Riccardo wrote: Hello, Hi Riccardo, I was building on netbsd ppc an intrp+jthread version (since pthreads are flawed in the kernel according to Guilhem) In file included from ../../../../kaffe/libraries/clib/fdlibm/mprec.h:34, from ../../../../kaffe/libraries/clib/fdlibm/dtoa.c:29: ./../../../kaffe/libraries/clib/fdlibm/ieeefp.h:160:2: #error Endianess not declared!! In file included from ../../../../kaffe/libraries/clib/fdlibm/dtoa.c:29: ./../../../kaffe/libraries/clib/fdlibm/mprec.h:75: error: parse error before one ./../../../kaffe/libraries/clib/fdlibm/mprec.h:75: warning: type defaults to `int' in declaration of `IEEE_8087' ./../../../kaffe/libraries/clib/fdlibm/mprec.h:75: warning: type defaults to `int' in declaration of `IEEE_MC68k' ./../../../kaffe/libraries/clib/fdlibm/mprec.h:75: warning: type defaults to `int' in declaration of `VAX' ./../../../kaffe/libraries/clib/fdlibm/mprec.h:75: warning: type defaults to `int' in declaration of `or' ./../../../kaffe/libraries/clib/fdlibm/mprec.h:75: error: parse error before IBM ./../../../kaffe/libraries/clib/fdlibm/mprec.h:86: error: parse error before '}' token ./../../../kaffe/libraries/clib/fdlibm/dtoa.c: In function `_Jv_dtoa_r': Darn, I thought Guilhem fixed and commited this. Or possibly he fixed and didn't commit and thus I wiped out his fix during a cvs update... This is the second solution. ;) I know what I've done though. But it is a generic fix for kaffe build structure and maybe Classpath's hackers are insterested in something more convenient to them to fix the same thing. Guilhem. -R ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] (Maybe Bug Report): kaffe-1.1.5: Garbage collector: threadData.jvmpiData not scanned for pointers
Hi, I am not a JVMPI expert but SetThreadLocalStorage is only there to record that some pointer is affected to some thread. I am not sure this must be walked by the GC as this may be a weak reference. The documentation on sun's site is not clear on that point and would require further testing to be sure of the semantic. By the way, it is not advised generally to mark an unknown object. Marking an unknown value can lead to crash (as when you mark you generally assume the value you give is a real heap pointer). In kaffe you will see there is only one place where you make random marking: the GC itself. And this is only after having checked we have a real heap pointer. Any JVMPI user around ? Regards, Guilhem. On Fri, 2005-06-24 at 17:31 +0400, Alexander Petrossian wrote: jvmpiSetThreadLocalStorage puts a pointer to local storage instances there: KTHREAD(get_data)(jt)-jvmpiData = ptr; but that field: threadData.jvmpiData is not scanned for pointers neither here liveThreadWalker [gc-refs.c] which only looks into thread_data-jnireferences nor anywhere else. the letters jvmpiData only occur in 3 places in source distribution: ./kaffe/jvmpi/ 431:jvmpi_kaffe.c jvmpiGetThreadLocalStorage 655:jvmpi_kaffe.c jvmpiSetThreadLocalStorage ./kaffe/kaffevm/ 25:threadData.hdeclaration this looks like a but to me, since if that storage would hold a last pointer to an object, that object will be reclaimed during garbage collect. test case for that should be obvious. I myself is not a java developer, I even have no kaffe binaries, so I can't run it. In case this is NOT a bug, please provide a short explanation to how that can work. Alexander Petrossian, Moscow, Russia. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Moving callMethodX
Hi, I'm proposing to move KaffeVM_callMethodX to its own file as they are very hackish and I need a few of the defined macros to write another machine dependent function to count the real number of arguments which will be used by callMethod. Anything against this ? Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] NPE while printing a stack trace
Hi Daniel, I've just fixed the problem in CVS head. Tell me if there's something else you see in the regression tests. :) Cheers, Guilhem. On Thu, 2005-06-09 at 18:26 +0200, Daniel Bonniot wrote: Helmer, thanks a lot for your fix! With the same setup, here is another bug (I have been seeing it for a lot time, but could not reproduce it reliably until now): $ cat trace.t /// PASS bug int[][] l = [[0,1],[1,2]]; int[] bar = l.map(T (T[] x) = x[1]); You have new mail. $ /usr/local/src/kaffe/install/bin/kaffe -cp /usr/share/java/nice.jar \ nice.tools.testsuite.TestNice -runtime /usr/share/java/nice.jar trace.t run test engine testsuite: trace.t java.lang.NullPointerException at java.lang.Object.getClass (Object.java:331) at java.lang.VMSystem.arraycopy (VMSystem.java:92) at java.lang.System.arraycopy (System.java:234) at java.lang.String.getChars (String.java:398) at java.lang.StringBuffer.append (StringBuffer.java:314) at java.lang.StackTraceElement.toString (StackTraceElement.java:193) at java.lang.Throwable.stackTraceStringBuffer (Throwable.java:477) at java.lang.Throwable.stackTraceString (Throwable.java:418) at java.lang.Throwable.printStackTrace (Throwable.java:398) at nice.lang.fun.printStackTraceWithSourceInfo (source file unknown:735) at nice.lang.dispatch.printStackTraceWithSourceInfo (source file unknown:line unknown, pc 0x93820a2) at nice.lang.fun.printStackTraceWithSourceInfo (source file unknown:line unknown, pc 0x9382110) at nice.lang.dispatch.printStackTraceWithSourceInfo (source file unknown:line unknown, pc 0x93822cb) at nice.tools.compiler.fun.compile (source file unknown:61) at nice.tools.testsuite.TestCase.compilePackage (TestCase.java:337) at nice.tools.testsuite.TestCase.compilePackages (TestCase.java:295) at nice.tools.testsuite.PassTestCase.performTest (PassTestCase.java:45) at nice.tools.testsuite.TestSuite.performTests (TestSuite.java:216) at nice.tools.testsuite.TestSuite.init (TestSuite.java:85) at nice.tools.testsuite.TestNice.performTests (TestNice.java:414) at nice.tools.testsuite.TestNice.main (TestNice.java:208) The good news is that after working around this bug (and lots of memory), kaffe can run Nice's entire testsuite with no bug (besides one that I already fixed in classpath). Awesome! So after this bug is fixed, things should start to look quite good from my point of view. Cheers, Daniel ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] gnu.java.nio.charset.iconv.IconvCharset cannot be used
Hi Ito,
Could you add (*env)-ExceptionDescribe(env) at the point where there is
a failed assertion. It should work now in any case. I guess that
FindClass returns NULL because it cannot find RawData* but we must
check.
Regards,
Guilhem.
On Sat, 2005-06-04 at 08:33 +0900, Ito Kazumitsu wrote:
Hi,
ChangeLog says:
2005-05-30 Helmer Kraemer [EMAIL PROTECTED]
* libraries/javalib/kaffe/lang/AppClassLoader.java,
libraries/javalib/kaffe/lang/PrimordialClassLoader.java,
libraries/clib/native/PrimordialClassLoader.c: removed. Loading
classes is
now handled completely by ClassLoader / VMClassLoader.
...
*
libraries/javalib/META-INF/services/java.nio.charset.spi.CharsetProvider:
removed, as iconv is treated specially by java.nio.charset.Charset
The removal of META-INF/... is OK for me because I prefer using my own
CharsetProvider wrapping gnu.java.nio.charset.iconv.IconvProvider.
But the following simple program dumps core. This problem did not occur
when kaffe.lang.*ClassLoader was used.
bash-2.05b$ cat TestCharsetProviderMain.java
import java.nio.charset.*;
import java.nio.charset.spi.*;
public final class TestCharsetProviderMain
{
public static void main(String[] args) throws Exception
{
Class c = Class.forName(gnu.java.nio.charset.iconv.IconvProvider,
true,
Thread.currentThread().getContextClassLoader());
System.out.println(c);
System.out.flush();
CharsetProvider p = (CharsetProvider)(c.newInstance());
System.out.println(p);
System.out.flush();
System.out.println(p.charsetForName(args[0]));
}
}
bash-2.05b$ kaffe TestCharsetProviderMain EUC-JP
class gnu.java.nio.charset.iconv.IconvProvider
[EMAIL PROTECTED]
charsetForName EUC-JP
IconvMetaData [EMAIL PROTECTED]
trying new IconvCharset(info)
Assertion failed: (cls != NULL), function createRawData, file
gnu_java_nio_charset_iconv_IconvEncoder.c, line 192.
Abort trap (core dumped)
Please note that some files are modified for debugging purpose:
--- gnu/java/nio/charset/iconv/IconvProvider.java.origSat Apr 23
18:54:27 2005
+++ gnu/java/nio/charset/iconv/IconvProvider.java Fri Jun 3 07:34:02 2005
@@ -62,7 +62,7 @@
}
}
- private IconvProvider()
+ public IconvProvider()
{
IconvMetaData.setup();
}
@@ -88,13 +88,23 @@
{
try
{
+ System.out.println(charsetForName + charsetName);
+ System.out.flush();
IconvMetaData info = IconvMetaData.get(charsetName);
+ System.out.println(IconvMetaData + info);
+ System.out.flush();
// Try anyway if the set isn't found.
if (info == null)
info = new IconvMetaData(charsetName, 2.0f, 2.0f, 2.0f, 2.0f,
new String[] { }, charsetName);
- return new IconvCharset(info);
+ System.out.println(trying new IconvCharset(info));
+ System.out.flush();
+ Charset cs = new IconvCharset(info);
+ System.out.println(new IconvCharset(info) + cs);
+ System.out.flush();
+ return cs;
+ // return new IconvCharset(info);
}
catch (IllegalArgumentException e)
{
Note: Without changing private IconvProvider() to public IconvProvider(),
an instance of this class cannot be created newInstance().
--- libraries/clib/nio/gnu_java_nio_charset_iconv_IconvEncoder.c.~1.3.~
Fri May 20 23:46:49 2005
+++ libraries/clib/nio/gnu_java_nio_charset_iconv_IconvEncoder.c Sat Jun
4 07:04:23 2005
@@ -79,6 +79,7 @@
if (infid == NULL || outfid == NULL)
{
cls = (*env)-GetObjectClass (env, obj);
+ assert (cls != NULL);
infid = (*env)-GetFieldID (env, cls, inremaining, I);
assert (infid != 0);
outfid = (*env)-GetFieldID (env, cls, outremaining, I);
@@ -183,10 +184,12 @@
#ifdef POINTERS_ARE_64BIT
cls = (*env)-FindClass (env, gnu/classpath/RawData64);
+ assert (cls != NULL);
method = (*env)-GetMethodID (env, cls, init, (J)V);
data = (*env)-NewObject (env, cls, method, (jlong) ptr);
#else
cls = (*env)-FindClass (env, gnu/classpath/RawData32);
+ assert (cls != NULL);
method = (*env)-GetMethodID (env, cls, init, (I)V);
data = (*env)-NewObject (env, cls, method, (jint) ptr);
#endif
Note: assert (cls != NULL) is also written in lookupClassMethod
in kaffe/kaffevm/support.c. Without inserting assert (cls != NULL)
here, the failure will be checked there.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] request for switching to subversion
On Thu, 2005-06-02 at 14:45 -0500, Adam Heath wrote: I've done a small straw poll on irc.kaffe.org#kaffe, to see what people think about switching kaffe away from cvs, and to svn. Everyone who's responded has been for the idea. So now, I'm posting publically. What do all the existing developers think about switching? Go for it !!! :) Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] port 1.1.5 on sxale---I have lost hope
Hi, The standard detection of stack boundaries involves the production of a segmentation violation by the program. It is caught by kaffe and handled correctly. You can safely ignore the message as kaffe seems to work. Regards, Guilhem. On Sun, 2005-05-01 at 17:36 +0800, huangtonglang wrote: hi all! I cross-compiled the kaffe 1.1.5 for xscale(linux 2.14.8). But when I ran the Helloworld on the target, I got the follow information: [EMAIL PROTECTED] bin]$./kaffe -vmdebug INIT HelloWorld initCollector() initCollector() done initNativeThreads(0x1) Detected stackSize 1048576 pc : [00060510] lr : [000604ec] Not tainted sp : b2a8 ip : 0017fd08 fp : b2d4 r10: 001897d0 r9 : 0001 r8 : bbb4 r7 : 0003 r6 : 0005 r5 : r4 : 00060438 r3 : b000 r2 : c000 r1 : b2b4 r0 : 1000 Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user Control: 397F Table: A3D18000 DAC: 0015 initNativeThreads(0x1) done utf8ConstInit() utf8ConstInit() done ... Hello World /// Does it mean that something wrong happened during initNativeThreads? The corsstoolchain is 2.95.3 thank you very much! ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: FAQ.debugging - additions - please review
On Sun, 2005-04-17 at 18:53 -0400, Michael Franz wrote: On 12/30/04, Michael Franz [EMAIL PROTECTED] wrote: Here is the diff -u . Any reason why this was not applied? Michael No special reason besides forgetting. :) Checking it in now. Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] warnings cleanup for amd64
On Sat, 2005-04-16 at 13:13 -0700, Eric Anholt wrote: Seeing only one regression failure on FreeBSD/amd64 (GCTest, which fails 100% of the time), I went on another warnings cleanup spree. No improvement in regressions, but fewer warnings as a result. It's mostly type cleanups, but there's one uninitialized variable fix to jni.c which looks important, and I think I set the correct initial value for it. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe Hi Eric ! I wonder why this patch is needed ? It obscures the type we really need. --- kaffe/kaffevm/intrp/icode.h 5 Feb 2005 09:22:42 - 1.23 +++ kaffe/kaffevm/intrp/icode.h 17 Apr 2005 16:20:33 - @@ -16,7 +16,7 @@ #include soft.h #if defined(KAFFE_VMDEBUG) -static const int32 UNINITIALIZED_STACK_SLOT = 0x00c0ffee; +static const long UNINITIALIZED_STACK_SLOT = 0x00c0ffee; #endif I'm ok for the rest. Cheers, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixlet for OS which do not support strerror_r
Hmmm... it seems kdevelop has a good indentation algorithm. I haven't noticed it has modified all these lines. Guilhem. On Sat, 2005-04-16 at 07:19 -0700, Kaffe CVS wrote: PatchSet 5677 Date: 2005/04/16 14:15:27 Author: guilhem Branch: HEAD Tag: (none) Log: Fixlet for OS which do not support strerror_r * libraries/clib/nio/gnu_java_nio_VMSelector.c (Java_gnu_java_nio_VMSelector_select): Use strerror instead of strerror_r if it is not available. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixlet for OS which do not support strerror_r
On Sat, 2005-04-16 at 14:53 -0500, Adam Heath wrote: On Sat, 16 Apr 2005, Guilhem Lavaux wrote: Hmmm... it seems kdevelop has a good indentation algorithm. I haven't noticed it has modified all these lines. That's why I always run diff before committing. Actually this should be the right indentation (according to michael) but for the sake of compatibility with GNU Classpath I will revert back the indentation. Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Bug report: Null WeakReference
Hi,
This bug has already been fixed in CVS head.
Thanks for reporting it.
Regards,
Guilhem.
On Thu, 2005-04-14 at 17:19 +0200, Laurent Martelli wrote:
The following class raises a NullPointerException with Kaffe because
of the null passed to the WeakReference constructor. It should not.
public class NullWeakRef {
public static void main(String[] args) {
new java.lang.ref.WeakReference(null);
}
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: mapping rt.jar
On Thu, 2005-04-14 at 14:29 +, Hammam Mounir wrote: hi; when i launch kaffe-bin the falowing error is showed : Hi, it looks like more a kernel bug than a kaffe one. I suggest you report this to your kernel's vendor and look at what he/she has to say about it. Regards, Guilhem. Unable to handle kernel NULL pointer dereference at virtual address 003f fault-common.c(97): start_code=0x6e0040, start_stack=0x7f7f90) Internal error: Oops: 0 CPU: 0 pc : [0003d2d8]lr : [0003d6dc]Not tainted sp : 006f1ef4 ip : 006f1f10 fp : 006f1f0c r10: r9 : 0003 r8 : 006f1f6c r7 : r6 : 006b9008 r5 : 006b9000 r4 : ffe8 r3 : r2 : 0003 r1 : 006f r0 : 006f1f24 Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: 107D thank you for help. regards. On 4/13/05, Guilhem Lavaux [EMAIL PROTECTED] wrote: On Wed, 2005-04-13 at 09:38 +, Hammam Mounir wrote: hi all; in file .../kaffevm/jar.c we need to map rt.jar file in memory (function OpenJarFile(..)), but uClinux does not support file mapping (CPU=ARM OS=uClinux). Hi, Normally openJarFile should handle systems which does not support the mmap syscall. In that case it fallbacks to using the classic input/output syscalls. Is there a specific error which is thrown by the compiler or the runtime ? Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] small kaffe-1.1.5 patch
Hi, Thanks for the bug report and the patch ! I'll commit it asap. Regards, Guilhem. On Tue, 2005-04-12 at 19:41 -0700, Mike Castle wrote: * Minor fix to include directories ordering In my case, I build kaffe with --prefix=/usr/X11R6. Since I had 1.1.4 installed already, it picked up the wrong jni.h and failed during compilation. This ensures that the included jni.h gets included first. To be honest, should probably move X_FLAGS down a line or two to be sure. mrc patch -p1 \EOF diff -ru kaffe-1.1.5.orig/libraries/clib/awt/classpath-gtk/gtk-peer/Makefile.am kaffe-1.1.5/libraries/clib/awt/classpath-gtk/gtk-peer/Makefile.am --- kaffe-1.1.5.orig/libraries/clib/awt/classpath-gtk/gtk-peer/Makefile.am 2005-04-05 12:48:02.0 -0700 +++ kaffe-1.1.5/libraries/clib/awt/classpath-gtk/gtk-peer/Makefile.am 2005-04-12 19:15:04.0 -0700 @@ -83,6 +83,7 @@ libjawt_la_CPPFLAGS = \ $(AM_CPPFLAGS) \ + -I$(top_srcdir)/include/ \ @X_CFLAGS@ \ -I$(top_srcdir)/libraries/clib/classpath/ \ -I$(top_builddir)/include/ EOF ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mapping rt.jar
On Wed, 2005-04-13 at 09:38 +, Hammam Mounir wrote: hi all; in file .../kaffevm/jar.c we need to map rt.jar file in memory (function OpenJarFile(..)), but uClinux does not support file mapping (CPU=ARM OS=uClinux). Hi, Normally openJarFile should handle systems which does not support the mmap syscall. In that case it fallbacks to using the classic input/output syscalls. Is there a specific error which is thrown by the compiler or the runtime ? Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] bug in jthreadedRecvfrom - patch for syscalls.c
On Tue, 2005-04-12 at 17:16 +0300, Nektarios K. Papadopoulos wrote: Hi all, the attached patch fix a bug in jthreadedRecvfrom. The case of NOTIMEOUT was not handled correctly, passing negative values to waitForTimeout. The result was maximum cpu consumption. Hi ! Thanks for the patch. I've modified it a bit just to compute poll_timeout only if we need it. There are no regressions... Cheers, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [EMAIL PROTECTED]: Default values for stack and heap size]
On Tue, 2005-04-12 at 12:45 -0400, Barry Hawkins wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Koch wrote: [...] I have a little feature request. Please output the default values for stak size, maximum and initial heap size. These values differ from arch to arch and tis hard to follow them. It would be convinient when they would be shown when calling kaffe -version or so. [...] +1 for that request You wanted it you got it ! :) I've added two output lines to printShortVersion() with the last patch. Cheers, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Jakarta-commons/collections
Hi, Just to mention that I've finally have made kaffe passed all tests on jakarta-commons/collections (0 failures). I will run some more tests on the other packages. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixlets + VMSelector merged back.
On Mon, 2005-04-11 at 23:22 +0900, Rei Odaira wrote:
Hi,
+ while (1)
+{
+ r = select (n, readfds, writefds, exceptfds, timeout ? delay :
NULL);
+
+ if (r 0 errno != EINTR)
+ return -errno;
+ else if (r = 0)
+ return r;
Could anyone replace this select() with KSELECT()?
Oooops. Ok, I've fixed my last commit. Thank you for reminding me of
it. :)
Regards,
Guilhem.
Thanks in advance,
Rei
Plain text document attachment (kaffe-VMSelector.patch)
Index: libraries/clib/nio/gnu_java_nio_VMSelector.c
===
RCS file: /cvs/kaffe/kaffe/libraries/clib/nio/gnu_java_nio_VMSelector.c,v
retrieving revision 1.10
diff -a -u -r1.10 gnu_java_nio_VMSelector.c
--- libraries/clib/nio/gnu_java_nio_VMSelector.c 10 Apr 2005 16:46:12
- 1.10
+++ libraries/clib/nio/gnu_java_nio_VMSelector.c 11 Apr 2005 14:25:24
-
@@ -36,6 +36,7 @@
exception statement from your version. */
#include config.h
+#include jsyscall.h
/* sys/types.h needs to be included on OSX before sys/select.h */
#if defined(HAVE_SYS_TYPES_H)
@@ -151,12 +152,15 @@
while (1)
{
- r = select (n, readfds, writefds, exceptfds, timeout ? delay : NULL);
+ int retcode;
- if (r 0 errno != EINTR)
- return -errno;
- else if (r = 0)
- return r;
+ r = KSELECT (n, readfds, writefds, exceptfds,
+timeout ? delay : NULL, retcode);
+
+ if (r == 0)
+ return retcode;
+ if (r != EINTR)
+ return -r;
/* Here we know we got EINTR. */
if ((*env)-
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [patch] Incorrect handling of a negative dividend in jit3
Hi Rei, Thanks ! I've checked the patch and it looks ok. There isn't any regression either. So I've checked it in. Regards, Guilhem. On Tue, 2005-04-12 at 01:10 +0900, Rei Odaira wrote: Hi, div_int_const_optimize() in jit3 cannot handle a negative dividend correctly. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Running Tomcat 5.0
Hi Rei,
Thanks for the patch ! I haven't yet reread it thoroughly though. As
this is a GNU Classpath bug it should also be sent to:
http://savannah.gnu.org/bugs/?group=classpath
Regards,
Guilhem.
On Sun, 2005-04-10 at 01:27 +0900, Rei Odaira wrote:
Fernando Lozano wrote:
Having read many reports on the archieve of success running Tomcat under
Kaffe, I decided to try myself using Tomcat 5.0.28. Although many JSP
pages and Servlets do run ok (icluding the Tomcat Manager and most
samples) many applications, including some examples and the Tomcat
Administrator fail with the following exception
java.lang.IllegalStateException: Zip file already closed:
/d/local/jakarta-tomcat-5.0.28/common/lib/commons-pool-1.2.jar
Any idea on how to workaround this, or should I fill a bug report? And
the bug report should go to Kaffe or Jakarta?
I have just found the cause of the problem.
org.apache.jasper.compiler.TldLocationsCache#scanJar() opens
commons-pool-1.2.jar, reads some entries, and finally closes it
when redeployMode == true, as shown below.
##
private void scanJar(JarURLConnection conn, boolean ignore)
throws JasperException {
JarFile jarFile = null;
String resourcePath = conn.getJarFileURL().toString();
try {
if (redeployMode) {
conn.setUseCaches(false);
}
jarFile = conn.getJarFile();
Enumeration entries = jarFile.entries();
...snip...
} finally {
if (redeployMode) {
// if in redeploy mode, always close the jar
if (jarFile != null) {
try {
jarFile.close();
} catch (Throwable t) {
// ignore
}
}
}
}
}
##
Since a JarURLConnection can internally cache JarFile objects,
scanJar() first disables the caching by calling setUseCaches(false)
when it wants to close the JarFile later. However,
gnu.java.net.protocol.jar.Connection, which extends JarURLConnection,
does not check for the useCaches flag when it opens a connection.
Therefore, the unintendedly cached JarFile object becomes stale
after it gets closed by scanJar(). If Tomcat re-opens
commons-pool-1.2.jar through JarURLConnection, it will get
the already closed JarFile object.
The attached patch fixes this problem.
Rei
Plain text document attachment (kaffe-jarconn.patch)
Index: libraries/javalib/gnu/java/net/protocol/jar/Connection.java
===
RCS file:
/cvs/kaffe/kaffe/libraries/javalib/gnu/java/net/protocol/jar/Connection.java,v
retrieving revision 1.8
diff -a -u -r1.8 Connection.java
--- libraries/javalib/gnu/java/net/protocol/jar/Connection.java 8 Mar
2005 21:03:53 - 1.8
+++ libraries/javalib/gnu/java/net/protocol/jar/Connection.java 9 Apr
2005 15:22:59 -
@@ -69,13 +69,18 @@
private static Hashtable cache = new Hashtable();
private static final int READBUFSIZE = 4*1024;
-public static synchronized JarFile get (URL url) throws IOException
+public static synchronized JarFile get (URL url, boolean use_caches)
throws IOException
{
- JarFile jf = (JarFile) cache.get (url);
+ JarFile jf;
+
+ if (use_caches)
+ {
+ jf = (JarFile) cache.get (url);
+
+ if (jf != null)
+ return jf;
+ }
- if (jf != null)
-return jf;
-
if (file.equals (url.getProtocol()))
{
File f = new File (url.getFile());
@@ -101,7 +106,8 @@
ZipFile.OPEN_READ | ZipFile.OPEN_DELETE);
}
- cache.put (url, jf);
+ if (use_caches)
+ cache.put (url, jf);
return jf;
}
@@ -120,7 +126,7 @@
return;
jar_url = getJarFileURL();
-jar_file = JarFileCache.get (jar_url);
+jar_file = JarFileCache.get (jar_url, useCaches);
String entry_name = getEntryName();
if (entry_name != null
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Running Tomcat 5.0
Hi,
No need to file the bug. I have done it myself.
Regards,
Guilhem.
On Sun, 2005-04-10 at 01:27 +0900, Rei Odaira wrote:
Fernando Lozano wrote:
Having read many reports on the archieve of success running Tomcat under
Kaffe, I decided to try myself using Tomcat 5.0.28. Although many JSP
pages and Servlets do run ok (icluding the Tomcat Manager and most
samples) many applications, including some examples and the Tomcat
Administrator fail with the following exception
java.lang.IllegalStateException: Zip file already closed:
/d/local/jakarta-tomcat-5.0.28/common/lib/commons-pool-1.2.jar
Any idea on how to workaround this, or should I fill a bug report? And
the bug report should go to Kaffe or Jakarta?
I have just found the cause of the problem.
org.apache.jasper.compiler.TldLocationsCache#scanJar() opens
commons-pool-1.2.jar, reads some entries, and finally closes it
when redeployMode == true, as shown below.
##
private void scanJar(JarURLConnection conn, boolean ignore)
throws JasperException {
JarFile jarFile = null;
String resourcePath = conn.getJarFileURL().toString();
try {
if (redeployMode) {
conn.setUseCaches(false);
}
jarFile = conn.getJarFile();
Enumeration entries = jarFile.entries();
...snip...
} finally {
if (redeployMode) {
// if in redeploy mode, always close the jar
if (jarFile != null) {
try {
jarFile.close();
} catch (Throwable t) {
// ignore
}
}
}
}
}
##
Since a JarURLConnection can internally cache JarFile objects,
scanJar() first disables the caching by calling setUseCaches(false)
when it wants to close the JarFile later. However,
gnu.java.net.protocol.jar.Connection, which extends JarURLConnection,
does not check for the useCaches flag when it opens a connection.
Therefore, the unintendedly cached JarFile object becomes stale
after it gets closed by scanJar(). If Tomcat re-opens
commons-pool-1.2.jar through JarURLConnection, it will get
the already closed JarFile object.
The attached patch fixes this problem.
Rei
Plain text document attachment (kaffe-jarconn.patch)
Index: libraries/javalib/gnu/java/net/protocol/jar/Connection.java
===
RCS file:
/cvs/kaffe/kaffe/libraries/javalib/gnu/java/net/protocol/jar/Connection.java,v
retrieving revision 1.8
diff -a -u -r1.8 Connection.java
--- libraries/javalib/gnu/java/net/protocol/jar/Connection.java 8 Mar
2005 21:03:53 - 1.8
+++ libraries/javalib/gnu/java/net/protocol/jar/Connection.java 9 Apr
2005 15:22:59 -
@@ -69,13 +69,18 @@
private static Hashtable cache = new Hashtable();
private static final int READBUFSIZE = 4*1024;
-public static synchronized JarFile get (URL url) throws IOException
+public static synchronized JarFile get (URL url, boolean use_caches)
throws IOException
{
- JarFile jf = (JarFile) cache.get (url);
+ JarFile jf;
+
+ if (use_caches)
+ {
+ jf = (JarFile) cache.get (url);
+
+ if (jf != null)
+ return jf;
+ }
- if (jf != null)
-return jf;
-
if (file.equals (url.getProtocol()))
{
File f = new File (url.getFile());
@@ -101,7 +106,8 @@
ZipFile.OPEN_READ | ZipFile.OPEN_DELETE);
}
- cache.put (url, jf);
+ if (use_caches)
+ cache.put (url, jf);
return jf;
}
@@ -120,7 +126,7 @@
return;
jar_url = getJarFileURL();
-jar_file = JarFileCache.get (jar_url);
+jar_file = JarFileCache.get (jar_url, useCaches);
String entry_name = getEntryName();
if (entry_name != null
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] gnu.java.nio.VMSelector implementation
Hi Rei, Thank you very much for the patch ! It looks good to me. The last two files should also be sent to GNU Classpath though. As they are trivial bugs I think there should not be any problem going into the CVS. I am committing this now. Regards, Guilhem. On Sun, 2005-04-03 at 17:04 +0900, Rei Odaira wrote: Dalibor Topic wrote: Rei Odaira wrote: Hi, I'm trying to run Tomcat 5 with clustering support on Kaffe/jthread. The current implementation of gnu.java.nio.VMSelector#select() seems to directly invoke a system call select(), instead of KSELECT(). Since the system call is not aware of jthread, Kaffe can stop indefinitely when java.nio.channels.Selector#select() is called with timeout == 0 (blocking mode). Below is a simple testcase. I think the previous implementation, which uses KSELECT(), would be better, although it has several serious bugs. Any thoughts? Konnichiwa Rei, Thanks you very much for spotting this bug, and for the great bug report! And thanks to Guilhem for checking in a fix so rapidly and fixing my mistake! :) Thanks to Guilhem for fixing the issue! But unfortunately, this is not the end of the problem. The attached patch will fix the following five bugs in the selector of Kaffe/jthread. o The parameter e of jthreadedSelect() can be NULL, which means an infinite timeout. In that case, time_milli should be NOTIMEOUT. o We must not pass parameters b, c, and d of jthreadedSelect() directly to the system call select(), because they can be changed by select(). o We must set maxFd, readsPending, and writesPending properly in jthreadedSelect(). o helper_select() in gnu_java_nio_VMSelector.c retuns EINTR when the current thread is interrupted. However, EINTR == 4 in Linux, so we cannot distinguish the interrupted case from the one where the number of bits set in the bit masks is 4. o java.nio.channels.spi.AbstractSelectableChannel#register() should throw IllegalBlockingModeException if the channel is in blocking mode. Rei ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] gnu.java.nio.VMSelector implementation
On Sun, 2005-04-03 at 12:28 +0200, Michael Koch wrote:
On Sun, Apr 03, 2005 at 05:04:32PM +0900, Rei Odaira wrote:
--- libraries/clib/nio/gnu_java_nio_VMSelector.c1 Apr 2005 01:02:56
- 1.5
+++ libraries/clib/nio/gnu_java_nio_VMSelector.c3 Apr 2005 07:24:27
-
@@ -166,7 +166,7 @@
/* Here we know we got EINTR. */
if ( (*env)-CallStaticBooleanMethod(env, thread_class,
thread_interrupted) )
{
- return EINTR;
+ return -2;
}
if (timeout)
@@ -249,7 +249,7 @@
result = helper_select (env, thread_class, thread_interrupted, max_fd +
1, read_fds, write_fds,
except_fds,
time_data);
- if( result == EINTR ) {
+ if( result == -2 ) {
/* The behavior of JRE 1.4.1 is that no exception is thrown
* when the thread is interrupted, but the thread's interrupt
* status is set. Clear all of our select sets and return 0,
Why do you do these? Using cryptic values withoud documenting it is at
least not good for maintaining the code? What does the -2 stands for?
We should use constant names wherever possible to make it easier to port
the code to other archs. E.g. On my Linux EINTR has the value 4 and
not -2. So this change looks just plain wrong for Linux.
Hi Michael,
You are right. We should not use raw integer value in the middle of the
code. However VMSelector should not use positive values to return an
interrupt event as it may be misunderstood in some circumstances when
you are only selecting on 4 descriptors (and then EINTR==4 :( ). I have
slightly modified the patch to use negative integer values to return
error code in kaffe. At the same time I've noticed that select0 was
using errno to check the error code (which is not right in our jthread
paradigm). This should be fixed now.
Regards,
Guilhem.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] missing ArrayIndexOutOfBoundsException in defineClass
On Sun, 2005-04-03 at 20:08 +0200, Christian Thalinger wrote: While testing and implementing CACAO's defineClass, if found this issue: $ cacao MyClassLoader Exception in thread main java.lang.ArrayIndexOutOfBoundsException No stacktrace available $ kaffe MyClassLoader class MyClassLoader Hi Christian, Thanks for pointing us the issue ! I have a fix for that in CVS now. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [Bug report]: JavaVMInitArgs in JNI not compatible with java 1.2
Nico Kasprzyk wrote: Hi, i just tried to use kaffe with our project which uses java code from within c++. Unfortunately, jni is not usable for me because its interface does not conform to java 1.2 which uses JavaVMOption objects to set e.g. the class path. Kaffe CVS head should be JNI 1.2 compliant (at least concerning the invokation interface because some JNI functions are still missing). Regards, Guilhem Lavaux. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ThreadLocalTest fails
Ito Kazumitsu wrote: ThreadLocalTest fails recently. It does not finish until killed by the killer process. Thanks Ito ! I'm also experiencing other deadlocks on freebsd. I'll have a look at where does they come from. Guilhem. bash-3.00$ uname -a FreeBSD mq.maczuka.gcd.org 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 bash-3.00$ /disk/kaz/work/kaffe-inst/bin/kaffe -fullversion Kaffe Virtual Machine Copyright (c) 1996-2004 Kaffe.org project contributors (please see the source code for a full list of contributors). All rights reserved. Portions Copyright (c) 1996-2002 Transvirtual Technologies, Inc. The Kaffe virtual machine is free software, licensed under the terms of the GNU General Public License. Kaffe.org is a an independent, free software community project, not directly affiliated with Transvirtual Technologies, Inc. Kaffe is a Trademark of Transvirtual Technologies, Inc. Kaffe comes with ABSOLUTELY NO WARRANTY. Engine: Just-in-time v3 Version: 1.1.x-cvs Java Version: 1.1 Configuration/Compilation options: Compile date : Wed Mar 16 01:02:48 JST 2005 Compile host : mq.maczuka.gcd.org Install prefix : /disk/kaz/work/kaffe-inst Thread system: unix-pthreads Garbage Collector: kaffe-gc CC : gcc CFLAGS : -g -O2 -Wchar-subscripts -Wcomment -Wformat=2 -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wswitch-default -Wswitch-enum -Wtrigraphs -Wunused-function -Wunused-label -Wunused-parameter -Wunused-variable -Wunused-value -Wunknown-pragmas -Wstrict-aliasing -W -Wfloat-equal -Wdeclaration-after-statement -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wpacked -Wredundant-decls -Wnested-externs -Winvalid-pch -Winline -Wlong-long -Wdisabled-optimization -no-cpp-precomp -D_THREAD_SAFE -pthread LDFLAGS : ChangeLog head : 2005-03-14 Dalibor Topic [EMAIL PROTECTED] And here is the message the regression test showed. TestScript ./ThreadLocalTest.java testing ./ThreadLocalTest.java JAVA_SRCS=./ThreadLocalTest.java jikes +Pno-switchcheck +Pno-shadow +E -nowarn -bootclasspath ../..//libraries/javalib/rt.jar -classpath .:@GNU_CRYPTO_JAR@:@JAVAX_SECURITY_JAR@:.:compile_time:.: -d . ./ThreadLocalTest.java /disk/kaz/work/kaffe-make-current/kaffe/kaffe/kaffe/kaffe-bin -Dgnu.classpath.home.url=file:///disk/kaz/work/kaffe-make-current/kaffe/test/regression/../../libraries/clib/ ThreadLocalTest Background pid: 80311 Killer process pid: 80312 with timeout of 900 seconds output differs from ThreadLocalTest.out, saving in ThreadLocalTest.fail FAIL: ThreadLocalTest.java The difference of ThreadLocalTest.fail from the expected output is only this: Timeout - 900 seconds - killed ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Re: Total irix breakage...
Riccardo wrote: Hello, I've applied the patch however I don't whether it has been activated (I've introduced a #define somewhere in config-jthreads.h). You may check this by putting a dprintf in setupSigAltStack. I've attached a patch for this. I get no output if I insert that print statement. P.S.: Can I see the ClassGC.fail ? glamdring 12% cat ClassGC.fail Assertion failed: EX, file ../../../../kaffe/kaffe/kaffevm/kaffe-gc/gc- mem.c, line 387 as most of the others... OK. If you want to test in the meanwhile (I'll try to build a test directly on irix this week-end) you can define SIGALTSTACK_NEEDS_END in signal.c and remove the dprintf. I don't yet see why ClassGC.fail has this error on pthreads. I'll have a look this week-end. -R ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Total irix breakage...
Riccardo wrote: Hey, I'll try pthreads later and possibly on the other irix box whith gcc 2. 95. running pthreads instead of jthreads makes only 20 reg. fail: BadFloatTest.fail IntfTest.fail CatchDeath.fail NetworkInterfaceTest.fail ClassGC.fail Preempt.fail DateFormatTest.failProcessTest.fail DoubleComp.fail PropertiesTest.fail DoubleCvt.fail RefTest.fail DoubleNeg. fail TestClassRef.fail DoublePrint.fail TestMessageFormat.fail finalexc.fail TestSerialFields.fail FPUStack.fail ZipTest.fail Guilhem: I remember you fixed jthreads on irix... did you forgot to commit the patch or did it instead break again? I've applied the patch however I don't whether it has been activated (I've introduced a #define somewhere in config-jthreads.h). You may check this by putting a dprintf in setupSigAltStack. I've attached a patch for this. Guilhem. P.S.: Can I see the ClassGC.fail ? Index: signal.c === RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/systems/unix-jthreads/signal.c,v retrieving revision 1.31 diff -u -r1.31 signal.c --- signal.c12 Mar 2005 16:08:11 - 1.31 +++ signal.c15 Mar 2005 18:28:40 - @@ -357,6 +357,7 @@ newstack.ss_flags = 0; stackp = KMALLOC(newstack.ss_size); #if defined(SIGALTSTACK_NEEDS_END) + dprintf(This OS needs the stack end !\n); newstack.ss_sp = (void *)((uintp)stackp + newstack.ss_size); #else newstack.ss_sp = stackp; ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[Fwd: Re: [kaffe] Eclipse locked with new lock API]
---BeginMessage--- Hi jserv, The deadlock is not due to the locking system but to some collision between Kaffe_rmRef and the garbage collector thread when this one is active. It is not a profound problem but we have just to realy take care of the locking sequence at that place. Regards, Guilhem. [EMAIL PROTECTED] wrote: Dear all, I just build fresh Kaffe with the new lock API committed by Guilhem Lavaux. However, it failed to get compiled, and then I attempt to fix that with the following patch: $ cvs diff -up kaffe/kaffevm/locks.c Index: kaffe/kaffevm/locks.c === RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/locks.c,v retrieving revision 1.57 diff -u -p -r1.57 locks.c --- kaffe/kaffevm/locks.c 11 Mar 2005 16:41:52 - 1.57 +++ kaffe/kaffevm/locks.c 12 Mar 2005 00:36:18 - @@ -218,6 +218,7 @@ slowLockMutex(iLock** lkp, iLock *heavyL iLock* volatile lk; jthread_t cur = KTHREAD(current) (); threadData *tdata; + static timespent lockTime; /* for measuring the heavy slowlocks */ DBG(SLOWLOCKS, dprintf(slowLockMutex(lk=%p, th=%p)\n, But I found the build of Kaffe encountered the locked Eclipse problem when the first screen show up, and I couldn't generate any mouse / keyboard events at all. The configuration of my build are: . x86 / JIT3 . unix-pthread . kaffe-gc I test with Eclipse 3.0.1. Could you please help me to fix this issue? Sincerely, Jim Huang ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ---End Message--- ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Lock patch
Helmer Krämer wrote: Guilhem Lavaux [EMAIL PROTECTED] wrote: Hi, I've just finished a functional patch for the locking system. I don't know yet how much slower it is. But I've already had some interesting results with some private app which was not working previously. If noone is against I will commit it on wednesday... If nobody owns the lock, the jthread_t of the current thread is stored in *lkp (afterwards called thin lock). If the same thread tries to lock the mutex again, or another thread tries to do so, a heavy lock will be allocated. If *lkp does not point to a heavy lock, a new one is allocated on the heap. To preserve the state of the lock when a thin lock is replaced by a heavy lock, new-holder is initialized with the current value of lk, and lockCount is set if necessary. Afterwards an attempt is made to install the heavy lock. If that doesn't work (either because the lock was freed or because another thread already installed a heavy lock), the heavy lock is freed and we start again with checking whether *lkp is a heavy lock. Once we got a heavy lock, we wait for the heavy lock to become usable by the current thread, just like your code does. What do you think of this? Hi Helmer, It is interesting as it puts back some quickness into locks_internal_lockMutex. However you are missing static heavy locks in this implementation. So maybe we should have a way to prepare those locks or we'll have to rely once again on my crappy implementation using the special 'lock_in_progress' iLock (because you have to protect the concurrent initialization of this heavylock). We cannot use malloc in getHeavyLock for static locks as we may use them in KaffeGC_malloc or KaffeGC_free (and imagine the horror ! ;) ). So I propose a 'initStaticLock' function which will call KSEM(init) basically and put the heavyLock pointer in 'iStaticLock.lk'. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Lock patch
Guilhem Lavaux wrote: Helmer Krämer wrote: Guilhem Lavaux [EMAIL PROTECTED] wrote: Hi, I've just finished a functional patch for the locking system. I don't know yet how much slower it is. But I've already had some interesting results with some private app which was not working previously. If noone is against I will commit it on wednesday... If nobody owns the lock, the jthread_t of the current thread is stored in *lkp (afterwards called thin lock). If the same thread tries to lock the mutex again, or another thread tries to do so, a heavy lock will be allocated. If *lkp does not point to a heavy lock, a new one is allocated on the heap. To preserve the state of the lock when a thin lock is replaced by a heavy lock, new-holder is initialized with the current value of lk, and lockCount is set if necessary. Afterwards an attempt is made to install the heavy lock. If that doesn't work (either because the lock was freed or because another thread already installed a heavy lock), the heavy lock is freed and we start again with checking whether *lkp is a heavy lock. Once we got a heavy lock, we wait for the heavy lock to become usable by the current thread, just like your code does. What do you think of this? I've forgotten another thing. I'm wrong not to call gc_free in putHeavyLock as we are leaking memory at that place (for objects I mean). If we want to cache the heavy lock we should either follow Tim's advice or transform the fixed memory allocation by a garbage collected memory. Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Lock patch
Timothy Stack wrote: On Mar 8, 2005, at 5:38 AM, Helmer Krämer wrote: If *lkp does not point to a heavy lock, a new one is allocated on the heap. Hi Tim, I just want to interject a little note here, which I'm not sure is even relevant... Basically, Pat Tullmann (i think) once observed that the maximum number of heavy locks needed by the system was the same as the number of threads in the system. In other words, every thread is either: running, blocked trying to obtain a lock, or blocked in an Object.wait(). Therefore, you could preallocate all of the lock objects when creating threads and not have to try and allocate memory when taking a lock. Of course, this may not apply anymore since y'all seem to be leaving the heavies in place. Anyways, there is an implementation of this in the janosvm if you're interested. Yep. I've though about caching the semaphore but not the heavy lock. As I've detected another deadlock with the new implementation I will stabilize it a little more then maybe add a cache in threadData as JanosVM do. Thanks Tim ! Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe fast locks against slower locks
Hi, I've been quite busy these latter days so I haven't yet a patch ready for locks. Here is a summary of the problems/solutions: * currently kaffe uses a fast lock mechanism which needs to work to get a unique pointer for each thread. These pointer represents the holder. The stack pointer is a good candidate and it gives also the possibility to handle quickly recursive locks (when there are not contended). * However there are two drawbacks (at least): 1) getHeavyLock is really slow because it uses a ksem semaphore in timeout mode. It also looks to me a bit unreliable because this is the same semaphore that is used for waking up locked threads. So the wrong thread may be catching the signal (I haven't really analyzed fully the code at this place so it may not be the case but a timeout is really bad anyway for a lock). Solution: use a specific heavy semaphore lock however all threads must be aware of it at the time it is used. 2) More problematic I've noticed that the JNI calls MonitorEnter and MonitorExit uses lockObject and so the stack pointers to handle recursive locks. This is not _right_ and even buggy in most cases as the stack is rewinded when lockObject exits. The specification says also that we must really take care of the number of times monitorenter has been called. Solution: use a real counter and not the stack pointer as the fast lock mechanism does not track the number of times MonitorEnter and MonitorExit has been called. Consequence: Either we use a standard pthread lock mechanism and locks.c transforms into a simple adaptative layer for jmutex_* and jcondvar_* functions (and so we must update jthreads' functions because they do not support recursive locks), or we keep the ksem implementation but implement a not so fast locking mechanism with also two layers (contended and not contended) and we give up stack pointers handling. I have already begun modifying locks.c in case we're ok to keep ksem's implementation. Any suggestion ? Any problems ? Any improvements ? Cheers, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Exit code when an exception was uncaught
Hi Daniel,
Thanks for the report. I don't know how I've managed to pass my test
previously however I have now a patch for this which fix the behaviour
of JNI_DestroyJavaVM (and consequently fix the problem you reported).
However this patch is only for unix-pthreads at the moment. I'll write
something for unix-jthreads asap and commit it.
Cheers,
Guilhem.
Daniel Bonniot wrote:
Guilhem Lavaux wrote:
Hi Daniel,
I had a few minutes free and checked it in the CVS. Now whenever there
is an uncaught exception happened kaffe-bin will return with 1 instead
of 0.
Cheers,
Guilhem.
Guilhem, thanks a lot for looking into this. However, I tried with the
latest Debian package, which includes your change, and it does not seem
to make any difference in this case. Here is the testcase, and
transcript while running with JDK and kaffe.
$ cat Field.java
class Field {
public static void main(String[] args)
{
throw new Error();
}
}
$ javac Field.java
$ java Field echo PS
Exception in thread main java.lang.Error
at Field.main(Field.java:4)
$ kaffe Field echo PS
java.lang.Error
at Field.main (Field.java:4)
PS
$ kaffe -fullversion
...
ChangeLog head : 2005-02-15 Guilhem Lavaux [EMAIL PROTECTED]
Cheers,
Daniel
PS: I checked, and unless I made a mistake, it did not look like it was
the kaffe shell script losing the exit code.
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Index: kaffe/kaffevm/systems/unix-pthreads/thread-impl.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/systems/unix-pthreads/thread-impl.c,v
retrieving revision 1.73
diff -u -r1.73 thread-impl.c
--- kaffe/kaffevm/systems/unix-pthreads/thread-impl.c 20 Feb 2005 00:55:48
- 1.73
+++ kaffe/kaffevm/systems/unix-pthreads/thread-impl.c 26 Feb 2005 15:51:34
-
@@ -1004,9 +1004,10 @@
*/
}
-/*
+/**
* Function to be called (by threads.c firstStartThread) when the thread leaves
- * the user thread function
+ * the user thread function. If the calling thread is the main thread then it
+ * suspend the thread until all other threads has exited.
*/
void
jthread_exit ( void )
@@ -1044,7 +1045,9 @@
}
for ( t=activeThreads; t != NULL; t = t-next ){
- if ( t != cur ) {
+ /* We must not kill the current thread and the main thread
+*/
+ if ( t != cur t != firstThread) {
/* Mark the thread as to be killed. */
t-status = THREAD_KILL;
/* Send an interrupt event to the remote thread.
@@ -1066,27 +1069,32 @@
#endif
if ( (cur != firstThread) (firstThread-active == 0) ) {
- /* if the firstThread has already been frozen, it's not in the
cache list */
- pthread_cancel( firstThread-tid);
+ /* if the firstThread has already been frozen,
+* it's not in the cache list. We must wake it up because
+* this thread is the last one alive and it is exiting. */
repsem_post (firstThread-sem);
}
- unprotectThreadList(cur);
- pthread_exit( NULL);
+ /* This is not the main thread so we may kill it. */
+ if (cur != firstThread)
+ {
+ unprotectThreadList(cur);
+ pthread_exit( NULL);
- /* we shouldn't get here, this is a last safeguard */
- EXIT(0);
+ /* we shouldn't get here, this is a last safeguard */
+ EXIT(0);
+ }
}
unprotectThreadList(cur);
}
- if ( cur == firstThread ) {
- /*
-* We don't cache this one, but we have to remove it from the active
list. Note
-* that the firstThread always has to be the last entry in the
activeThreads list
-* (we just add new entries at the head)
-*/
- protectThreadList(cur);
+ /*
+ * We don't cache this one, but we have to remove it from the active list.
Note
+ * that the firstThread always has to be the last entry in the activeThreads
list
+ * (we just add new entries at the head)
+ */
+ protectThreadList(cur);
+ if ( cur == firstThread nonDaemons != 0) {
/* if we would be the head, we would have been the last, too (and
already exited) */
assert( cur != activeThreads);
@@ -1097,22 +1105,15 @@
unprotectThreadList(cur);
- /*
-* Put us into a permanent freeze to avoid shut down of the whole
process (it's
-* not clear if this is common pthread behavior or just a implementation
-* linux-threads feature)
+ /* Put the main thread in a frozen state waiting for the other
+* real threads to terminate. The main thread gets the control back
+* after that.
*/
repsem_wait( cur-sem);
-
- /* We put here a safe-guard in case
Re: [kaffe] kaffe.def commands
Michael Franz wrote: Hi, I have been going over kaffe.def and slots.h to figure out how the interpreter works. I understand what the slots.h macros are doing (stack, pop, push, ) but I don't understand what the logical difference is amoung rstack, wstack and stack? I am thinking Read stack, Write stack and just a generic stack accessor. Is this at all correct? Yes. Correct. (Look at jit3/slots.h and jit/slots.h) Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Bug report: support.c:707
Hi Max,
I have tried to reproduce it without success so far. I'll try again on a
debian/linux 2.4 this evening. Meanwhile you can enable the production
of core dumps (ulimit -c 10 e.g.) start kaffe and get the stack
trace of the problem using gdb.
gdb /home/max/sys/kaffe/jre/bin/kaffe-bin core.
(where core. is the the name of the core dump)
Type where or bt to get the stack trace and send it to the ML.
Cheers,
Guilhem.
Max Gilead a écrit:
On Mon, 14 Feb 2005, pancake wrote:
for me it works fine.
Building with sun's javac looks like everything goes 'fine' (except for swing
bugs in gnuclasspath).
But building it under jikes. also works fine but show this Exception:
I don't know what is the difference but today I checked it again, building
with Sun's javac, Kaffe's javac and jikes - each time it crashes with the
same error I mentioned the first time. Below I paste the log of what I
did.
Any hints about how to debug it further?
Thanks,
Max
[EMAIL PROTECTED]:~/JTableTest$ ls
JTableTest.java
[EMAIL PROTECTED]:~/JTableTest$ /home/max/sys/kaffe/bin/javac JTableTest.java
[EMAIL PROTECTED]:~/JTableTest$ /home/max/sys/kaffe/bin/java JTableTest
kaffe-bin: support.c:707: lookupClassMethod: Assertion `cls != 0 name
!= 0 sig != 0' failed.
Aborted
[EMAIL PROTECTED]:~/JTableTest$ rm *class
[EMAIL PROTECTED]:~/JTableTest$ /home/max/sys/jdk/bin/javac JTableTest.java
[EMAIL PROTECTED]:~/JTableTest$
bin/java JTableTest
kaffe-bin: support.c:707: lookupClassMethod: Assertion `cls != 0 name
!= 0 sig != 0' failed.
Aborted
[EMAIL PROTECTED]:~/JTableTest$ rm *class
[EMAIL PROTECTED]:~/JTableTest$ jikes -cp /home/max/sys/kaffe/jre/lib/rt.jar
JTableTest.java
[EMAIL PROTECTED]:~/JTableTest$ /home/max/sys/kaffe/bin/java JTableTest
kaffe-bin: support.c:707: lookupClassMethod: Assertion `cls != 0 name
!= 0 sig != 0' failed.
Aborted
[EMAIL PROTECTED]:~/JTableTest$
[EMAIL PROTECTED]:/tmp$ /usr/pkg/java/kaffe-cvs/bin/kaffe JTableTest
Exception during event dispatch:
java.awt.IllegalComponentStateException: component not showing
at java.awt.Component.getLocationOnScreen (Component.java:1137)
at javax.swing.SwingUtilities.convertPointToScreen (SwingUtilities.java:323)
at javax.swing.SwingUtilities.convertPoint (SwingUtilities.java:380)
at javax.swing.SwingUtilities.convertRectangle (SwingUtilities.java:418)
at javax.swing.RepaintManager.paintDirtyRegions (RepaintManager.java:440)
at javax.swing.RepaintManager$RepaintWorker.run (RepaintManager.java:104)
at java.awt.event.InvocationEvent.dispatch (InvocationEvent.java:191)
at java.awt.EventQueue.dispatchEvent (EventQueue.java:416)
at java.awt.EventDispatchThread.run (EventDispatchThread.java:81)
at java.lang.VMThread.run (VMThread.java:124)
[EMAIL PROTECTED]:/tmp$
On Mon, 14 Feb 2005 15:57:54 +0100 (CET)
Max Gilead [EMAIL PROTECTED] wrote:
import java.awt.Dimension;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JTable;
public class JTableTest
{
public static void main(String[] args)
{
Object[][] data = new Object[100][3];
for (int i = 0; i data.length; i++)
{
data[i][0] = a+i;
data[i][1] = b+i;
data[i][2] = c+i;
}
JTable table = new JTable(data, new Object[] { A, B, C });
JFrame frame = new JFrame();
JPanel panel = new JPanel();
panel.add(new JScrollPane(table));
panel.setPreferredSize(new Dimension(200, 300));
frame.setContentPane(panel);
frame.pack();
frame.setVisible(true);
}
}
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Exit code when an exception was uncaught
Hi Daniel, I had a few minutes free and checked it in the CVS. Now whenever there is an uncaught exception happened kaffe-bin will return with 1 instead of 0. Cheers, Guilhem. Daniel Bonniot a écrit: Hi list, When execution terminates because an exception was thrown and never caught, kaffe still exits with a 0 exit code. It would make sense to have some non-zero code in that case, to notify that something went wrong. Sun's JVM exits with 1 in that case. Cheers, Daniel ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] linux/x86 regr. failures
Riccardo wrote: Hey, linux/x86 1 of 147 tests failed cat RefTest.fail Reference cleared Reference not cleared finalizer called Hi, Yeah. I know this one. When I have some time, I try to remove the alloca hack I've added for the finalizer but it's difficult as I cannot act on the pthread_* functions which may leave some uninitialized variable which contain the pointer which is holding the reference. Cheers, Guilhem. I also wonder if output like this Method Constant Pool: Translating StaticMethodCall.int_method_int_int(II)I (static) 0x81b3a30 soft_fixup_trampoline(): return 0x81b3a30 Success 0003 field: test__int_call_int_int2 = 0x0002 callinfo = 0xbfffe920 Method: StaticMethodCall.int_call_int_int2()I @0: iconst 1 @1: iconst 2 @2: invokestatic 47 @5: ireturn c: pushl ebp c: movl esp,ebp c: subl #?,esp is normal ? ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Java/JNI references for kaffe
Hi, I am sending a patch for the current Kaffe source tree to enable Java and JNI support for references. Before I commit there are still some issues to solve: * RefTest does not successfully pass the second reference clearing. The finalizer is invoked but the GC never destroy the object (GC bug ?). * Copyright notices aren't there. * There are no differences between the different reference flavour. Implementing this would require a modification to kaffe-gc which will be able to chose between 'must free' and 'should free'. :) Cheers, Guilhem Lavaux. P.S.: This diff has been generated before Dalibor's last patch. P.P.S.: As it is a big I am sending it in compressed form. ref_patch.gz Description: Unix tar archive ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Bytecode fails verification when anonymous class inherits inner class of another class.
Ito Kazumitsu wrote: In message Re: [kaffe] Bytecode fails verification when anonymous class inherits inner class of another class. on 05/01/19, Ito Kazumitsu [EMAIL PROTECTED] writes: This problem must have something to do with kjc/kjc/JConstructorCall.java. Although I am not sure what I am doing, I have found that the attached patch helps solve the problem. Thanks Ito. I'll take a look at the 'else' condition this week. If we continue to use kjc it will be useful to resync the directory structure of the kjc module too. That way we could submit our patch more easily to DMS (which I was a bit lazy to do :( ). Regards, Guilhem Lavaux. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [gump] utf8const.c
Helmer Krämer wrote: Guilhem Lavaux [EMAIL PROTECTED] wrote: Helmer Krämer wrote: Davanum Srinivas [EMAIL PROTECTED] wrote: looks like we need a lock for locking access to utfLockRoot :( I'd think that the whole utfLockRoot thing is broken (you'd need one utfLockRoot per thread since it's perfectly legal for two threads to work on utf8 constants at the same time). However, I think we could just remove the utfLockRoot thing completely, couldn't we? Even if one of the allocations in utf8const.c triggers a garbage collection, the thread holding the utf8Lock will be resumed before the finaliser starts to free unreachable objects (at least with kaffe-gc). This means that we don't have to drop the lock before doing an allocation, which renders utf8LockRoot useless. Or I just overlooked something ... Regards, Helmer The problem is that utf constants are cached in a hash table. If two strings are exactly equals then utf8const does not create a new constant. I don't know if the approach is justified but this justifies the use UTF locking as only one thread at a time should touch the hashtable. Yeah, it's supposed to work pretty much like String.intern() works. The assertion failure in itself is disturbing: it's like the fast lock subsystem is not working properly as it lets at least two threads running concurrently on that part of the code. UTFmalloc and UTFfree drop the utf8Lock before gc_malloc (or gc_free) and try to reacquire it afterwards. To do this, they use utfLockRoot to save the id of the thread holding the lock. So it looks like this is not working properly, but I'm also not sure whether we really need this: Dropping the lock before invoking gc_malloc / gc_free only makes sense if a deadlock might occur if a thread holds the utf8Lock and is suspended in gc_malloc or gc_free. The gc thread itself however, will never try to acquire the utf8Lock, as it only scans the memory but neither allocates nor frees utf8 constants. The only gc-related thread that might try to acquire the utf8Lock is the finaliser thread, but that one can't cause a deadlock as the thread that invoked gc_malloc/gc_free will already have been resumed when the finaliser thread is running. So I think we could use the normal lockStaticMutex/unlockStaticMutex functions to lock/unlock the utf8Lock and don't have to drop the utf8Lock during the calls to gc_malloc / gc_free (which means that we don't need the utfLockRoot variable any more). Hi, Yes. Maybe this will improve performance. However our problem will still be there... There is another performance penalty I've seen in locks.c: we are using KSEM(get) in getHeavyLock with a timeout. The timeout is expected to be the only signal which will make the call exit. This is unwise and we should have a mechanism to wake up one of the waiting thread. BTW, there is maybe something wrong here because a KSEM(put) can be caught by this KSEM(get) and not by the other one in slowLockMutex if the threads (3 at least) are wrongly synchronized. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Character encoder/ClassLoader initialization
Hi, It seems that when we don't use iconv there are some problems in initializing the EncodingManager. CharToByteConverter.getEncoder needs ClassLoader.getSystemResource which needs ClassLoader.staticData. However staticData is not yet initialized because getEncoder is called while initializing ClassLoader.StaticData.systemClassLoader. Everything goes to a NPE. The initialization loop can be broken either: * by removing the dependency on getSystemResource (but I bet it will be difficult) * by getting rid of AppClassLoader which is the source of the loop: it uses URLClassLoader. Any other idea ? Regards, Guilhem Lavaux. Please check your CLASSPATH and your installation. java/lang/Error: Unexpected problems with default encoder at java.lang.VMThrowable.fillInStackTrace(VMThrowable.java:native) at java.lang.VMThrowable.fillInStackTrace(VMThrowable.java:76) at java.lang.Throwable.fillInStackTrace(Throwable.java:498) at java.lang.Throwable.init(Throwable.java:159) at java.lang.Error.init(Error.java:81) at gnu.java.io.EncodingManager.getEncoder(EncodingManager.java:387) at java.io.OutputStreamWriter.init(OutputStreamWriter.java:114) at java.io.PrintWriter.init(PrintWriter.java:121) at java.io.PrintWriter.init(PrintWriter.java:137) at java.io.PrintStream.init(PrintStream.java:152) at java.lang.System.clinit(System.java:45) at java.security.SecureClassLoader.init(SecureClassLoader.java:61) at java.net.URLClassLoader.init(URLClassLoader.java:548) at kaffe.lang.AppClassLoader.init(AppClassLoader.java:237) at kaffe.lang.AppClassLoader.clinit(AppClassLoader.java:35) at java.lang.VMClassLoader.getSystemClassLoader(VMClassLoader.java:273) at java.lang.ClassLoader$StaticData.clinit(ClassLoader.java:160) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:772) ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Native library load failure - debug output
Michael Franz wrote:
Hi,
When running (trying to run) kaffe on darwin/x86 I get the same native
library load issue as on darwin/ppc (I think this is currently fixed),
however, for the PPC version the paths are complete and on x86 there
are relative. Is there code that is making them complete for certain
platforms?
Hi,
I guess this is the same problem I've encountered on openbsd. But the
fix is different as darwin is using a 'dyld' system and not a 'ld'
system. So here is patch to test.
Regards,
Guilhem.
x86
Failed to locate native library libnative in path:
../../libraries/clib/native/:../../libraries/clib/io/:../../libraries/clib/zip/:../../libraries/clib/nio/:../../libraries/clib/security/:../../libraries/clib/classpath/
ppc
---
Failed to locate native library libnative in path:
/Users/mfranz/development/tinderbox/tinderclient/kaffe/kaffe/libraries/clib/native:/Users/mfranz/development/tinderbox/tinderclient/kaffe/kaffe/libraries/clib/net:/Users/mfranz/development/tinderbox/tinderclient/kaffe/kaffe/libraries/clib/io:/Users/mfranz/development/tinderbox/tinderclient/kaffe/kaffe/libraries/clib/nio:/Users/mfranz/development/tinderbox/tinderclient/kaffe/kaffe/libraries/clib/zip:/Users/mfranz/development/tinderbox/tinderclient/kaffe/kaffe/libraries/clib/management:/Users/mfranz/development/tinderbox/tinderclient/kaffe/kaffe/libraries/clib/security
Michael
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Index: libraries/javalib/Makefile.in
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/Makefile.in,v
retrieving revision 1.372
diff -u -r1.372 Makefile.in
--- libraries/javalib/Makefile.in 8 Jan 2005 19:25:15 - 1.372
+++ libraries/javalib/Makefile.in 9 Jan 2005 15:28:37 -
@@ -399,7 +399,7 @@
KAFFELIBRARYPATH =
$(top_builddir)/libraries/clib/native/:$(top_builddir)/libraries/clib/io/:$(top_builddir)/libraries/clib/zip/:$(top_builddir)/libraries/clib/nio/:$(top_builddir)/libraries/clib/security/:$(top_builddir)/libraries/clib/classpath/
BOOTCLASSPATH = $(LIBDIR):$(srcdir)/Klasses.jar.bootstrap
JAR = BOOTCLASSPATH=$(BOOTCLASSPATH) KAFFELIBRARYPATH=$(KAFFELIBRARYPATH)
$(JAVA) kaffe.tools.jar.Jar
-LD_LIBRARY_PATH = $(top_builddir)/libraries/clib/classpath/
+DYLD_LIBRARY_PATH = $(top_builddir)/libraries/clib/classpath/
jrelib_DATA = \
rt.jar \
logging.properties
@@ -5781,7 +5781,7 @@
build-classes Klasses: rt.jar
all-am: rebuildLib
-export JIKES top_builddir LIBDIR srcdir LD_LIBRARY_PATH
+export JIKES top_builddir LIBDIR srcdir DYLD_LIBRARY_PATH
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
Index: Makefile.in
===
RCS file: /cvs/kaffe/kaffe/Makefile.in,v
retrieving revision 1.191
diff -u -r1.191 Makefile.in
--- Makefile.in 22 Dec 2004 19:04:37 - 1.191
+++ Makefile.in 9 Jan 2005 15:30:56 -
@@ -974,7 +974,9 @@
echo
BOOTCLASSPATH=\$${BOOTCLASSPATH}\''$(PATHSEP)'\'$(top_builddir)/libraries/javalib/rt.jar\''$(PATHSEP)'\'$(DNSJAVA_JAR)\'$(JAVAX_CRYPTO_JAR)\''$(PATHSEP)'\;
export BOOTCLASSPATH | sed 's,/,$(DIRSEP),g;s,\\,,g'
BUILD_ENVIRONMENT.new; \
echo
CLASSPATH=.\''$(PATHSEP)'\'\$${GNU_CRYPTO_JAR}\''$(PATHSEP)'\'\$${JAVAX_SECURITY_JAR}\''$(PATHSEP)'\'$(top_srcdir)/libraries/javalib/kjc.jar\''$(PATHSEP)'\'$(BCEL_JAR)\''$(PATHSEP)'\'$(GNU_CRYPTO_JAR)\''$(PATHSEP)'\'$(JAVAX_SECURITY_JAR)\;
export CLASSPATH | sed 's,/,$(DIRSEP),g;s,\\,,g' BUILD_ENVIRONMENT.new;
\
echo
KAFFELIBRARYPATH=\$${KAFFELIBRARYPATH+\\$$KAFFELIBRARYPATH\\''$(PATHSEP)'\'}`for
f in $(JAVA_LIBS); do echo $$f | sed 's%/[^/]*$$%%'; done | (tr '\012' ' ';
echo) | sed -e 's/ $$//' -e s/ /\'$(PATHSEP)\'/g`\; export KAFFELIBRARYPATH
BUILD_ENVIRONMENT.new; \
- echo JAVA=$(top_builddir)/kaffe/kaffe/kaffe-bin$(EXEEXT)\; export JAVA
BUILD_ENVIRONMENT.new
+ echo JAVA=$(top_builddir)/kaffe/kaffe/kaffe-bin$(EXEEXT)\; export JAVA
BUILD_ENVIRONMENT.new; \
+ echo DYLD_LIBRARYPATH=$(top_builddir)/libraries/clib/classpath/.libs;
export DYLD_LIBRARY_PATH BUILD_ENVIRONMENT.new; \
+ echo LD_LIBRARYPATH=$(top_builddir)/libraries/clib/classpath/.libs;
export LD_LIBRARY_PATH BUILD_ENVIRONMENT.new
rm -f BUILD_ENVIRONMENT
mv BUILD_ENVIRONMENT.new BUILD_ENVIRONMENT
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] jnirefs.h - is this needed
Michael Franz wrote: Thanks to your question I have reread the JNI spec and it looks like we should on the contrary enable the JNI refs. They are not needed in most cases because we store objects on the stack but if the native call stores object in the heap we may lose track of used objects and garbage collects them though we should not. I don't know why they have been disabled by helmer (?) http://www.kaffe.org/cgi-bin/cvsweb/kaffe/kaffe/kaffevm/Attic/jnirefs.h.diff?r1=1.1r2=1.2 Are we going to be enabling this? I am working on it. It will come with the patch I'm preparing to support java.lang.ref in kaffe. Regards, Guilhem. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
