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) {
> ArrayList a = new ArrayList();
> 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] Future directions for Kaffe
Hi Jim ! Kaffe has been quite dormant these weeks and it is also probably my fault. I am just damn busy with ph.d work. * I like Kaffe because it has helped me learn a lot of things from computers without hurting me too much by looking at large project. Also I guess kaffe can still be easily ported to other architecture. * I have a partly working new jit3-v2.0 which is able to cope with 64 bits arch. AMD64 is still giving some failures in the test suite (something like 30 failures for 160 tests). I will update the other jit3 when I have this one working. I hope to anyway check it in CVS after the next release. * AWT needs some work. I have not had time to check by myself but Riccardo reported there was problems running it. It will also be great to finish porting our X native peerless AWT to make it work with Classpath's "Swing" toolkit. * On the hosting part, I am fairly open. Having a personnal webserver has certainly its advantages but sourceforge.net, savannah ... may handle cvs/svn directly in a more efficient way. I would vote to keep our webserver for testing purpose though (running qemu-vm, having a tinderbox...) and maybe the handling of webserver. Cheers, Guilhem. Jim Pick wrote: > Hi everybody, > > It's been a quiet month on the mailing list so far. That's partly my > fault, I think, since the mailing list was broken for some time. > > It looks like the last CVS commit was 5 weeks ago. > > I see Dalibor went to FOSDEM, and did some talking about Kaffe there. > So I'm assuming that the project isn't dead, it's just somewhat dormant. > It's been somewhat dead/dormant throughout much of it's history, but > it's still here, isn't it? :-) > > And clearly, all the free Java runtimes and Classpath are in a state of > transition, as we wait for Sun to release the rest of OpenJDK. > > I'd like to liven up the list a bit, and maybe start a bit of discussion > on where Kaffe should go next. > > Here are some things I'd like to talk about: > > * I definitely need to do some work on upgrading the server, and fixing > up the website. Currently it's running a really old version of Debian, > so it needs to be upgraded. I'm just scared of all the breakage that > will happen. I'm slowly building up my hosting capabilities, but it's > just a hobby, and I have real life things going on, so I move at a > glacial pace. If anybody wants to help out with any of that, I'd really > appreciate it. I happy to keep hosting it indefinitely. > > * I think a wiki running on top of Kaffe would be really nice. :-) > > * On the other hand, there are establishing free software hosting > platforms like Sourceforge, Savannah, Google Code, etc. that might > work better than just running everything on our own server. Our current > infrastructure is pretty much still using technology from the 1990s. We > don't even have a blog or a wiki, or any continuous integration or > distributed version control. I'm open to migrating things if that's > what people would prefer. > > * Technically speaking, I'm still the project leader, by virtue of > rescuing it from the ashes of Transvirtual. But Dalibor is really the > guy who has been doing most of the work. I'm not really doing much with > Kaffe personally, so if anybody else wants to step up and be a real > project leader, feel free to volunteer. I'm still happy to keep hosting > the project and helping out with the releases. > > * Speaking of releases, we really should do another release sometime. > > * I'm embarrassed to admit that I don't even have Kaffe running on my > new MacBook under OS X. I got it to compile, but I couldn't get it to > even run "Hello World". If I spent some time on it, I imagine I could > figure it out. I just haven't spent the time. I hope it still runs OK > on Linux, but I haven't tried that recently either. > > * I also haven't been responding to emails asking me for help getting > Kaffe to run. I'd like to, but since I don't even have it working for > myself, I'm not really in a position to help out. I get so much spam > nowadays that I hardly even use email anymore. I notice that most > requests for help to the mailing list are going unanswered as well. > > * I'm still interested in playing with Java virtualization, and I'm very > excited about OpenJDK coming out. JRuby looks really interesting to me. > For my own projects, I'm guessing I'd probably use OpenJDK in > preference to Kaffe in the future, since it's likely to be a lot less > effort to get it working the way I want it to. > > * That said, I think Kaffe has been a seminal project in terms of > getting free Java off the ground, and I'd hate to see it die. A lot of > interesting projects have used Kaffe as a starting point. > > * I imagine that in the future, people will most likely look to OpenJDK > as a starting point to add their enhancements. Is there still a role > for Kaffe to play here? > > * I think Kaffe probably is still the simplest full JVM im
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 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] 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] 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
Re: [kaffe] GC Documentation
Hi ! Yes. There is no real documentation for the GC. I am one of the maintainer and actually I don't that much time for anything but fixing it. If you have questions to build a consistent documentation I can answer you though. Regards, Guilhem. Jim White wrote: [EMAIL PROTECTED] wrote: Hi ! We are waiting for the kaffe Garbage Collector documentation. Why don't you send us ? Kaffe has a free source code so why is it a problem for you to send us the GC documentation ? It is difficult understand the GC only from the GC source code and from the short description in the F.A.Q. section. Please, send us the GC source code documentation. Thanks. I would like to reply in an amusingly rhetorical fashion because I did get a chuckle from your post. But I know humor doesn't cross language and culture barriers very well, so I'll refrain. Given that: A) Documentation in OSS projects is much less common than code (because most programmers naturally prefer to write code rather than documentation and they usually have no incentive to do anything they don't feel like doing for OSS). and: B) Documentation is so valuable (useful for the reasons you cite but rare for the reasons in A) that it would be unusual indeed for it to be omitted from an OSS project web site. I'm sure you can deduce that the most likely reason you've received no response is that no further Kaffe-specific GC documentation exists. A great way for a new programmer to contribute to an OSS project is to write documentation. By writing down the things you learn and problems you solve while figuring out how the system works, you answer exactly the questions other new developers have. This is how OSS works. You might even be able to get some class credit from your professor. I hope I've been helpful. Jim White ___ 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: 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
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
[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] problems compiling kaffe-1.1.6 with alsa-lib-1.0.11_rc2
Hi Joshua, I am not sure it is a kaffe bug or a alsa-lib bug (for having removed quietly two macro definitions). I have checked in a patch in cvs to verify that the two macros are defined before using them. It should not change the behaviour and make the code compile. Regards, Guilhem. Joshua Nichols wrote: Hey folks, Over in Gentoo land, we recently received a bug report [1] about kaffe-1.1.6 fails to compile against alsa-lib-1.0.11_rc2. Figured you guys would like to know. [1] http://bugs.gentoo.org/show_bug.cgi?id=119272 Regards, Josh Nichols Gentoo Developer ___ 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] failed assertion with Eclispe
Hi you two, It would be nice to have a core dump to analyze. You should recompile kaffe with 'O0' (to be sure to have all symbols correct in gdb) and then we'll analyze the core dump. Regards, Guilhem. Wolfgang Baer wrote: Riccardo wrote: Hey, after running and typing in Eclipse for quire some time, kaffe crashed! (orthanc:~/eclipse302) multix% kaffe-bin: ../../../../kaffe/kaffe/kaffevm/jit3/machine.c:271: translate: Assertion `reinvoke == false' failed. on linux, x86, jit3 Thats the same as I reported on IRC yesterday with tomcat 5.0.30 Also linux, x86, jit3 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] error building kaffe 1.1.6
Hi, Alsa-lib headers have changed between 1.0.10 and 1.0.11-rc2 (seq.h). They have removed two constants (I don't know why). I think we will have to introduce further checkings in tritonus for these two constants. :( Regards, Guilhem. George P Nychis wrote: Hi, Just yesterday I was able to make a complete build of Kaffe 1.1.6. Today I updated "world" in Gentoo, and it will no longer build. I changed no source code and even tried redownloading, cleaning, and re-making. Here is the error i get: In file included from org_tritonus_lowlevel_alsa_AlsaSeq.c:25: constants_check.h: In function `check_constants': constants_check.h:139: error: `SND_SEQ_CLIENT_DUMMY' undeclared (first use in this function) constants_check.h:139: error: (Each undeclared identifier is reported only once constants_check.h:139: error: for each function it appears in.) constants_check.h:140: error: `SND_SEQ_CLIENT_OSS' undeclared (first use in this function) make[3]: *** [libtritonusalsa_la-org_tritonus_lowlevel_alsa_AlsaSeq.lo] Error 1 make[3]: Leaving directory `/home/hedpe/school/Kaffe/kaffe-1.1.6/libraries/clib/sound/alsa' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/hedpe/school/Kaffe/kaffe-1.1.6/libraries/clib/sound' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/hedpe/school/Kaffe/kaffe-1.1.6/libraries/clib' make: *** [all-recursive] Error 1 Any ideas? Thanks! George ___ 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] 1.1.7-rc1
Wolfgang Baer wrote: Linux ursus 2.6.14 #1 PREEMPT Tue Nov 1 12:05:33 CET 2005 i686 GNU/Linux SecurityMan2 fails on both jthreads/pthreads with the message below: $ cat build/pthreads/test/regression/SecurityMan2.fail java.lang.NoClassDefFoundError: java/security/Permission at SecurityMan2$MySM.checkPermission (SecurityMan2.java:17) at java.lang.SecurityManager.checkCreateClassLoader (SecurityManager.java:394) at java.lang.ClassLoader. (ClassLoader.java:276) at java.lang.ClassLoader. (ClassLoader.java:254) at java.security.SecureClassLoader. (SecureClassLoader.java:61) at java.net.URLClassLoader. (URLClassLoader.java:605) at SecurityMan2.main (SecurityMan2.java:29) As this test was just recently committed by Guilhem I cannot say if it worked at some time :-) I have checked it in because it should work now. :) Previously it was surely not working. I wonder why you get this though. I do not get the error here. Regards, Guilhem. ___ 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): 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] 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): 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.
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.
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] 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] PROBLEM WITH INITTHREADS-FUNCTION
Hi Daniel, BTW, I have just noticed that you have mentioned kaffe-1.0.7. This kaffe is very old and you should try to port kaffe CVS to eCos. Is it possible to get the modification so that they will be included in the next kaffe ? Thanks ! 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] 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] 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 {
}
___
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] Compile problems
Hi Jari,
What kind of signal is it ? Could you run kaffe with '-vmdebug INIT' ?
I am thinking of two possibilities:
* stack boundary detection (which uses SEGV)
* GC handling (which uses a couple of signal to stop/start the VM).
Cheers,
Guilhem.
Jari Korva wrote:
Hi,
I haven't progressed much. It would help *a lot* if someone who
understands how Kaffe works would tell who is supposed to send that
signal so it would be easier to find out why it is not done :)
I have also observed some variety in how Kaffe behaves. In some very rare
cases I have got it to print the HelloWorld message but usually it just
hangs before that.
Cheers,
Jari
On Fri, 18 Nov 2005, Rafael Teixeira wrote:
Hi Jari and Kaffe-List:
I'm also stuck with Kaffe stopping on startup on my XScale (IXP42x)
hardware. To add some more info we've tried with JamVM and SableVM,
and similar behaviour occurs, our next try is to use Mono with IKVM,
to see if we can get a single VM to startup our java firmware in the
XScale.
By tracing a bit, sure things look like your unanswered post on Signal
Waiting was in the right track, but with JamVM we are sometimes able
to get a simple "Hello World" to work, and sometimes it also hangs.
Jari, Have you been able to go further?
Thanks for any information, and we will be glad to share what we find
on our quest to make Kaffe work on XScale.
Regards,
--
Rafael Teixeira
On 11/18/05, Jari Korva <[EMAIL PROTECTED]> wrote:
Hi,
I observed a few problems while compiling Kaffe cvs head:
**
Classpath configure fails due to missing X libraries although X and
GTK are disabled in Kaffe configure script:
# ./configure --prefix=/wrk/kaffe.intrp --build=i686-linux
--host=armv5b-softfloat-linux --enable-xscale --without-x
--disable-alsatest --disable-esdtest --disable-sound
--enable-pure-java-math --with-jikes=/opt/local/bin/jikes
--without-classpath-gtk-awt --without-kaffe-qt-awt --without-kaffe-x-awt
--with-threads=unix-pthreads --with-engine=intrp
...
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t
*inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for X... disabled
configure: error: GTK+ peers requested but no X library available
configure: error: /bin/sh './configure' failed for
libraries/javalib/external/classpath
I was able to fix this by doing a manual classpath configure (with
--disable-gtk-peer):
# cd libraries/javalib/external/classpath
# ./configure --prefix=/wrk/kaffe.intrp --build=i686-linux
--host=armv5b-softfloat-linux --enable-xscale --without-x
--disable-alsatest --disable-esdtest --disable-sound
--enable-pure-java-math --with-jikes=/opt/local/bin/jikes
--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 host_alias=armv5b-softfloat-linux
--enable-ltdl-convenience --disable-core-jni --disable-examples
--with-glibj-dir=/wrk/kaffe.intrp/jre/lib
--with-native-libdir=/wrk/kaffe.intrp/jre/lib/arm
--with-vm-classes=/wrk/kaffe-cvs-head/libraries/javalib/vmspecific
--cache-file=/dev/null --srcdir=. --disable-gtk-peer
**
The 2nd problem is that configure fails when cross compiling for
ARM/XScale:
...
checking for esd-config... /usr/bin/esd-config
checking for ESD - version >= 0.2.1... yes
Information: Using pure Java math library
checking which extensions to include...
checking if malloc debugging is wanted... no
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for /proc/self/maps... configure: error: cannot check for file
existence when cross compiling
I was able to fix this with the patch below:
--- config/arm/linux/config.frag20 Jan 2005 23:19:18 - 1.8
+++ config/arm/linux/config.frag18 Nov 2005 12:46:49 -
@@ -12,4 +12,5 @@
ac_cv_func_mmap_fixed_mapped=${ac_cv_func_mmap_fixed_mapped='yes'}
# ac_cv_func_utime_null=${ac_cv_func_utime_null='yes'}
ac_cv_c_char_unsigned=${ac_cv_c_char_unsigned='no'}
+ ac_cv_file__proc_self_maps=${ac_cv_file__proc_self_maps='yes'}
fi
**
Cheers,
Jari
--
- Jari Korva -
- [EMAIL PROTECTED] -
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
- Jari Korva -
- [EMAIL PROTECTED] -
- +358-40-756 4812 -
___
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 (alex): initial checkin of DROPS port
Hi Alex, Could you write a small changelog for this checkin ? That way we can track more easily the different authors of kaffe. Thanks ! Regards, Guilhem. Kaffe CVS wrote: PatchSet 6968 Date: 2005/11/25 13:41:27 Author: alex Branch: HEAD Tag: (none) Log: initial checkin of DROPS port Members: configure.ac:1.186->1.187 config/i386/drops/config.frag:INITIAL->1.1 config/i386/drops/jit-md.h:INITIAL->1.1 config/i386/drops/jit3-md.h:INITIAL->1.1 config/i386/drops/md.c:INITIAL->1.1 config/i386/drops/md.h:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/Makefile.am:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/Makefile.frag:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/Makefile.in:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/jsignal.h:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/jthread.h:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/l4_loader.h:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/l4thread.c:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/l4thread.h:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/lock-impl.h:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/signal.c:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/syscalls.c:INITIAL->1.1 kaffe/kaffevm/systems/drops-l4threads/thread-impl.h:INITIAL->1.1 ___ 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] 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] 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] 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] problems with thread and ServerSocket.close()
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.
Hi Jean-Frederic,
Thanks for the bug report. I am quite slow to answer because I am
currently very busy with my real world work. I am confirming your bug
report. Though the behaviour of sockets is not really specified by the
java documentation when doing simultaneous system calls (We already had
some discussion about it for some other problem). Apparently we will
have to support it explicitly in some cases. I will try to think about
some safe way to do it in Classpath/kaffe.
Thanks !
Regards,
Guilhem.
/*
* Copyright 1999-2004 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/* @version $Id: JFCtest.java 165001 2005-04-27 16:01:42Z jfclere $ */
import java.io.*;
import java.net.*;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Enumeration;
import java.util.Vector;
public class JFCtest implements Runnable {
private ServerSocket server=null;
private Thread thread=null;
private boolean stopping=false;
private Vector handlers=null;
public static native void toto();
public JFCtest() {
super();
System.err.println("JFCtest: instance "+this.hashCode()+
" created");
this.handlers=new Vector();
}
protected void finalize() {
System.err.println("JFCtest: instance "+this.hashCode()+
" garbage collected");
}
/**
* init and destroy were added in jakarta-tomcat-daemon.
*/
public void init()
throws Exception {
System.err.println("JFCtest: instance "+this.hashCode()+
" init");
int port=1200;
/* Dump a message */
System.err.println("JFCtest: loading on port "+port);
this.server=new ServerSocket(port);
this.thread=new Thread(this);
}
public void start() {
/* Dump a message */
System.err.println("JFCtest: starting");
/* Start */
this.thread.start();
}
public void stop()
throws IOException, InterruptedException {
/* Dump a message */
System.err.println("JFCtest: stopping");
/* Close the ServerSocket. This will make our thread to terminate */
this.stopping=true;
// this.server.setSoTimeout(10);
System.err.println("JFCtest: stopping: before close");
// this.thread.interrupt();
this.server.close();
System.err.println("JFCtest: stopping: after close");
/* Wait for the main thread to exit and dump a message */
try {
this.thread.join(5000);
} catch (InterruptedException e) {
}
System.err.println("JFCtest: stopped");
}
public void destroy() {
System.err.println("JFCtest: instance "+this.hashCode()+
" destroy");
}
public void run() {
int number=0;
System.err.println("JFCtest: started acceptor loop");
try {
while(!this.stopping) {
Socket socket=this.server.accept();
Handler handler=new Handler(socket,this);
handler.setConnectionNumber(number++);
new Thread(handler).start();
}
} catch (IOException e) {
/* Don't dump any error message if we are stopping. A IOException
is generated when the ServerSocket is closed in stop() */
if (!this.stopping) e.printStackTrace(System.err);
e.printStackTrace(System.err);
}
/* Terminate all handlers that at this point are still open */
Enumeration openhandlers=this.handlers.elements();
while (openhandlers.hasMoreElements()) {
Handler handler=(Handler)openhandlers.nextElement();
System.err.println("JFCtest: dropping connection "+
handler.getConnectionNumber());
handler.close();
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] 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/cha
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
[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] 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
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
[kaffe] Classpath merge
Hi,
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. 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.
Cheers,
Guilhem.
___
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
Re: [kaffe] [newbie] gc implementation in kaffe
Dalibor Topic wrote: siddharth karandikar wrote: Hi all, I was going through the code of boehm-gc ... but i am not getting the big picture of how it is implemeted in kaffe ... lets say if i want to do some modifications to the GC behaviour ... i need to know the exact data structures which are getting used. so, can anyboby give me some information on these lines .. ? The gc source code in essentially split in several levels: kaffe/kaffevm/gc*.[ch] : gc interface & helper functions kaffe/kaffevm/boehm-gc/gc*.[ch] : boehm-gc binding for kaffe kaffe/kaffevm/boehm-gc/boehm/ : boehm gc. without forgetting kaffe/kaffevm/kaffe-gc/* for an independent implementation of a GC for kaffe. Cheers, Guilhem Lavaux. ___ 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 > > (): 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
> #include
> #include
> #include
>
> 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.
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. (Throwable.java:159)
>at java.lang.Error. (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[] 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. (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, "", "(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, "", "(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/k
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
On Thu, 2005-05-05 at 18:47 +0800, huangtonglang wrote: > Hi, > Why the sgmentation violation is produced, is that because the linux > kernel(2.4.18) on my xscale is too low or other course? I have tried > serval toolchain(3.4.1,3.3.2),but the results is no different. > If I can't fix it,how can I clear away the message which is very > boring. The segv must be produced however it must be hidden by the kernel by sending a SIGSEGV to kaffe (which looks like doing as kaffe runs after the message). The only possibility if you cannot disable the message printed by the kernel is to disable stack detection and use another heuristic. However we are not providing heuristic change at configure time. Also, are you using glibc ? If it's the case we may avoid using the segv handler to detect stack. Be aware that we are also handling some NullPointerException through the sigsegv catching and so may get some of these for incorrectly written java program. Regards, Guilhem Lavaux. > Thank you for your help! > > 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 : [] lr : [] 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 > > > > > > > > > > > > ääéçåäæåéå3äçæåïåèååçï > > > > > > > > ääéçåäæåéå3äçæåïåèååçï > > ___ > 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] 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
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] TestSerializable2 fix for amd64.
Hi Kurt ! Thanks for the patch. It is perfect for me and I'm checking it in asap. Regards, Guilhem. On Sat, 2005-04-16 at 02:21 +0200, Kurt Roeckx wrote: > Hi, > > It seems that the TestSerializable2 failure I've been seeing on > amd64 is caused by using an int instead of a ssize_t. See the > last part of the diff for the fix. > > I've also fixed a printf() call where it was just using %d > instead of %zd to print a ssize_t. > > > Kurt > > ___ > 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): 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] Jakarta-commons/collections
On Tue, 2005-04-12 at 17:49 -0400, Barry Hawkins wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Guilhem Lavaux wrote: > > 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. > [...] > Guilhelm, > Did you test against the 2.1 stream or 3.x stream for commons > collections? What do you mean ? I'm using CVS head of jakarta-commons. Regards, Guilhem. > > Thanks, > - -- > Barry Hawkins > All Things Computed > site: www.alltc.com > weblog: www.yepthatsme.com > > Registered Linux User #368650 > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFCXEJ2HuKcDICy0QoRAjPiAKDpRcUDdw9NIg+jwUIXZ8jSM/VTcgCg23oG > hYXEHYobjRCcI4sRb4otpns= > =cGOZ > -END PGP SIGNATURE- ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] fix configure --enable-xslttest
Hi,
Thanks for reporting the bug. I've made the modification to
m4/libxslt.m4. Dalibor, if you have some time could you have a look for
updated m4 in the original packages ?
Regards,
Guilhem.
On Wed, 2005-04-13 at 15:12 +0300, Nektarios K. Papadopoulos wrote:
> Hi,
>
> I use CVS Head (or 1.1.5) on linux-x86. When I configure using
> --enable-xslttest
> I get the following error:
>
> ...
> checking for libxml - version >= 2.6.8... yes (version 2.6.16)
> checking for xslt-config... /home/u2/npapadop/devel/libxsl/bin/xslt-config
> checking for libxslt - version >= 1.1.11... no
> *** Could not run libxslt test program, checking why...
> *** The test program failed to compile or link. See the file config.log for
> the
> *** exact error that occured. This usually means LIBXSLT was incorrectly
> installed
> *** or that you have moved LIBXSLT since it was installed. In the latter case,
> you
> *** may want to edit the xslt-config script:
> /home/u2/npapadop/devel/libxsl/bin/xslt-config
> configure: error: unable to locate libxslt.
>
>
>
> Looking in the config.log I see that:
>
> ...
> configure:47806: checking for libxslt - version >= 1.1.11
> configure:47913: gcc -o conftest -g -O2 -Wall -pthread
> -I/home/u2/npapadop/devel/x86-linux-libxslt-1.1.13/include
> -I/home/u2/npapadop/devel/x86-linux-libxml2-2.6.17/include/libxml2
> -D_REENTRANT -DKAFFE_VMDEBUG -D_REENTRANT conftest.c
> -L/home/u2/npapadop/devel/x86-linux-libxslt-1.1.13/lib
> -L/home/u2/npapadop/devel/x86-linux-libxml2-2.6.17/lib -lxslt -lxml2 -lz
> -lpthread -lm -L/usr/lib -lxml2 -lz -lpthread -lm >&5
> conftest.c: In function `main':
> conftest.c:246: error: `LIBXSLT_DOTTED_VERSION' undeclared (first use in this
> function)
> conftest.c:246: error: (Each undeclared identifier is reported only once
> conftest.c:246: error: for each function it appears in.)
> conftest.c:269: error: `LIBXSLT_VERSION_STRING' undeclared (first use in this
> function)
>
>
> I am using libxslt-1.1.13 from source. configure and make install to a
> directory
> of my own. grep-ing the headers I see that the ofending
> LIBXSLT_VERSION_STRING
> is defined in which is never included.
>
> The attached patch fixed this for me.
>
> Cheers,
> Nek
> plain text document attachment (configure_xslttest.patch)
> Index: configure
> ===
> RCS file: /cvs/kaffe/kaffe/configure,v
> retrieving revision 1.443
> diff -u -r1.443 configure
> --- configure 5 Apr 2005 03:32:32 - 1.443
> +++ configure 13 Apr 2005 12:08:41 -
> @@ -47843,6 +47843,7 @@
> #include
> #include
> #include
> +#include
> int
> main()
> {
> ___
> 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] 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
[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] 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
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
[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] [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
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] [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] 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"
>
> /* needs to be included on OSX before */
> #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] 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();
> ..
>
> } 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 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();
> ..
>
> } 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] 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 > <> > $ 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] 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] 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] [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
