Re: [kaffe] Rebuilding all sources
Pinaki Mukherjee ([EMAIL PROTECTED]) wrote: Actually, I am not adding or deleting any file, rather changing the -O2 option to -O0. Any quick pointer? make clean env CFLAGS=-g -O0 ./configure # plus whatever other options you need make -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | signature.asc Description: Digital signature ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Newbie Problem on OpenBSD 3.4
Dalibor Topic ([EMAIL PROTECTED]) wrote: Kaffe 1.0.7 had some problems wrt libtool on i386-openbsd [1]. You could give kaffe 1.1.4 a spin, it should be better in that respect, since it uses a newer libtool, with our OpenBSD patches merged in. :) OpenBSD on i386 used a.out in versions 3.3 and earlier. But the person who started this thread is using 3.4, which is ELF-based on i386. This removes most if not all of the libtool weirdness. I'd suggest using kaffe for running the java bytecode, and jikes for compiling it, assuming he can get jikes working properly. (When I was running Freenet on Kaffe on OpenBSD, I was either using pre-built Freenet .jar files, or building them with jikes on Linux. I stopped for multiple reasons, the first of which was the extensive use of non-blocking I/O in Freenet, which Kaffe didn't support at the time. Not sure what its status is at the moment.) -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | signature.asc Description: Digital signature
Re: [kaffe] Which libtool?
James Simmons ([EMAIL PROTECTED]) wrote: debian stable with libtool 1.5 automake 1.7.6 autoconf 2.57 Woody (Debian stable) has: autoconf 2.53 automake 1.4-p4 libtool 1.4.2 Whatever you're running, it's not woody any more. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
[kaffe] java.text.SimpleDateFormat.formatWithAttribute
Engine: Just-in-time v3 Version: 1.1.1 Java Version: 1.1 Configuration/Compilation options: Compile date : Mon Aug 25 18:44:22 EDT 2003 Compile host : pegasus Install prefix: /usr/local/kaffe Thread system : unix-jthreads CC: gcc CFLAGS: -g -O2 -Wall -Wstrict-prototypes LDFLAGS : ChangeLog head: 2003-08-25 Mark Wielaard [EMAIL PROTECTED] $ java freenet.node.Main java.lang.NullPointerException at java.text.SimpleDateFormat.formatWithAttribute (SimpleDateFormat.java:541) at java.text.SimpleDateFormat.format (SimpleDateFormat.java:551) at java.text.DateFormat.format (DateFormat.java:73) at freenet.support.FileLoggerHook.log (FileLoggerHook.java:241) at freenet.support.Logger.log (Logger.java:94) at freenet.support.Logger.log (Logger.java:70) at freenet.node.Main.main (Main.java:947) OpenBSD 3.3 i386, Kaffe was just updated from CVS a few minutes ago. The node does not start up; the NPE is very soon after issuing the command. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] Playing with freenet...
Jim Pick ([EMAIL PROTECTED]) wrote: Here's the key for the site: [EMAIL PROTECTED]/jimpick/1// I've managed to find the front page through my Kaffe node. (My Linux/Sun node hasn't found it yet, though. Perhaps it's a Sun anti-competitive feature? ;-) ) -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] #if 0
Rob Gonzalez ([EMAIL PROTECTED]) wrote: In kaffe/kaffevm/exceptions.c, around throwOutOfMemory there is a #if 0 preprocessing block...what exactly does #if 0 mean? Everything between #if 0 and #endif (or #else) will be ignored by the C compiler. It's a common way to comment out a huge block of code, even if that block contains /* comments */ of its own. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
[kaffe] Kaffe vs. Freenet round (N+2): nio
20:12 greycat is nio going to be mandatory in 0.5.2? this is going to screw kaffe users 20:13 toad_ greycat: yes. kaffe users can fix the bugs. $ ln -sf freenet-nio-20030616.jar freenet.jar $ java freenet.node.Main java.lang.UnsatisfiedLinkError: Failed to locate native function: gnu/java/nio/SocketChannelImpl.SocketCreate()I at gnu.java.nio.ServerSocketChannelImpl.init(ServerSocketChannelImpl.java:70) at gnu.java.nio.SelectorProviderImpl.openServerSocketChannel(SelectorProviderImpl.java:75) at java.nio.channels.ServerSocketChannel.open(ServerSocketChannel.java:90) at freenet.transport.TCP$privServerSocketFactory.createServerSocket(TCP.java:129) at freenet.transport.tcpNIOListener.startListener(tcpNIOListener.java:62) at freenet.transport.tcpNIOListener.init(tcpNIOListener.java:50) at freenet.transport.tcpNIOListener.init(tcpNIOListener.java:36) at freenet.interfaces.PublicNIOInterface.init(PublicNIOInterface.java:46) at freenet.node.Main.startNode(Main.java:1292) at freenet.node.Main.main(Main.java:868) Dumping live threads: `QThread-6' tid 0xc51010, status SUSPENDED flags [EMAIL PROTECTED] (0xc51010-|) `QThread-5' tid 0xc46010, status SUSPENDED flags [EMAIL PROTECTED] (0xc46010-|) `QThread-4' tid 0xc17010, status SUSPENDED flags [EMAIL PROTECTED] (0xc17010-|) `QThread-3' tid 0xc01010, status SUSPENDED flags [EMAIL PROTECTED] (0xc01010-|) `QThread-2' tid 0xbee010, status SUSPENDED flags [EMAIL PROTECTED] (0xbee010-|) `QThread-1' tid 0xbdd010, status SUSPENDED flags [EMAIL PROTECTED] (0xbdd010-|) `Thread creation thread.' tid 0xbbd010, status SUSPENDED flags [EMAIL PROTECTED] (0xbbd010-|) `Background inserter' tid 0xb5b010, status SUSPENDED flags [EMAIL PROTECTED] (0xb5b010-|) `Diffie-Helman-Precalc' tid 0x73f010, status SUSPENDED flags [EMAIL PROTECTED] (0x73f010-|) `Log File Writer Thread' tid 0x679010, status SUSPENDED flags [EMAIL PROTECTED] (0x679010-|) `gc' tid 0x1d0010, status SUSPENDED flags DONTSTOP [EMAIL PROTECTED] (0x1d0010-|) `finaliser' tid 0x1c7010, status SUSPENDED flags DONTSTOP [EMAIL PROTECTED] (0x1c7010-|) Deadlock: all threads blocked on internal events Abort (core dumped) (gdb) bt #0 0x40215fcf in _thread_sys_kill () #1 0x402158bb in abort () #2 0x40057434 in onDeadlock () at thread.c:603 #3 0x4007e2d8 in reschedule () at jthread.c:1679 #4 0x4007ceda in killThread (tid=0xd9050) at jthread.c:364 #5 0x4007e0c6 in jthread_exit () at jthread.c:1580 #6 0x400571c0 in exitThread () at thread.c:439 #7 0x4004a893 in Kaffe_DestroyJavaVM (vm=0x400b3c74) at jni.c:3530 #8 0x1b64 in main2 (env=0x0, argv=0xcfbfda40, farg=2, argc=0) at main.c:238 #9 0x199d in main (argc=2, argv=0xcfbfda40) at main.c:145 Engine: Just-in-time v3 Version: 1.1.x-cvs Java Version: 1.1 Configuration/Compilation options: Compile date : Fri Jun 13 18:41:35 EDT 2003 Compile host : pegasus Install prefix: /usr/local/kaffe Thread system : unix-jthreads CC: gcc CFLAGS: -g -O2 -Wall -Wstrict-prototypes LDFLAGS : ChangeLog head: 2003-05-11 Dalibor Topic [EMAIL PROTECTED] -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] (sigh) Kaffe 1.1 can't do FEC decoding
Dalibor Topic ([EMAIL PROTECTED]) wrote: Hm, any chance of pinpointing the exact checkin on kaffe that started failing FEC ? kaffe -fullversion of the last version that works, kaffe -fullversion of the first version that fails, and an ugly binary search over checkouts, I guess ;) There have been quite a few changes to the core libraries in the last 4 weeks. In each case below, I checked out CVS, removed the /usr/local/kaffe symlink, did a ./configure --enable-debug --with-includes=/usr/local/include --with-libraries=/usr/local/lib, then vi libtool, gmake, gmake install, then renamed /usr/local/kaffe to /usr/local/kaffe-May-NN and made /usr/local/kaffe a symlink to kaffe-May-NN. Then I renamed servlet.jar within /usr/local/kaffe-May-NN/jre/lib to disabled.servlet.jar and did my testing. After testing, I did a gmake distclean before the next checkout. From the freenet point of view, what I did was create a new user account, drop freenet.jar and freenet-ext.jar and seednodes.ref into its home dir, ran java freenet.node.Main --config and set it up as a transient on a randomly chosen port with defaults for everything else. I inserted a 2.3 MB file using java freenet.client.cli.Main --htl 0 put CHK@ filename, and then with each version of Kaffe I attempted to retrieve it with java freenet.client.cli.Main --htl 0 --healPercentage 0 get [EMAIL PROTECTED] newfilename. cvs -z3 update -dP -D May 10 - success cvs -z3 udpate -dP -D May 20 - failure 13-Jun-03 6:35:34 PM (freenet.interfaces.LocalInterface, Interface # tcp/8481, ERROR): Unhandled throw accepting connections: Interface # tcp/8481 java.lang.NullPointerException at freenet.transport.tcpConnection.init(tcpConnection.java:123) at freenet.transport.tcpListener.accept(tcpListener.java:48) at freenet.interfaces.Interface.acceptConnections(Interface.java:217) at freenet.interfaces.Interface.run(Interface.java:172) at java.lang.Thread.run(Thread.java:334) cvs -z3 update -dP -D May 15 - success cvs -z3 update -dP -D May 17 - failure 13-Jun-03 6:55:00 PM (freenet.interfaces.LocalInterface, Interface # tcp/8481, ERROR): Unhandled throw accepting connections: Interface # tcp/8481 java.lang.NullPointerException at freenet.transport.tcpConnection.init(tcpConnection.java:123) at freenet.transport.tcpListener.accept(tcpListener.java:48) at freenet.interfaces.Interface.acceptConnections(Interface.java:217) at freenet.interfaces.Interface.run(Interface.java:172) at java.lang.Thread.run(Thread.java:334) cvs -z3 update -dP -D May 16 - no files changed from May 17, so didn't run -fullversion for the broken May 17th build: Engine: Just-in-time v3 Version: 1.1.x-cvs Java Version: 1.1 Configuration/Compilation options: Compile date : Fri Jun 13 18:51:45 EDT 2003 Compile host : pegasus Install prefix: /usr/local/kaffe Thread system : unix-jthreads CC: gcc CFLAGS: -g -O2 -Wall -Wstrict-prototypes LDFLAGS : ChangeLog head: 2003-05-15 Tim Stack [EMAIL PROTECTED] -fullversion for the working May 15th build: Engine: Just-in-time v3 Version: 1.1.x-cvs Java Version: 1.1 Configuration/Compilation options: Compile date : Fri Jun 13 18:41:35 EDT 2003 Compile host : pegasus Install prefix: /usr/local/kaffe Thread system : unix-jthreads CC: gcc CFLAGS: -g -O2 -Wall -Wstrict-prototypes LDFLAGS : ChangeLog head: 2003-05-11 Dalibor Topic [EMAIL PROTECTED] CVS/Tag for the May 16th checkout which is the same as May 17th: D2003.05.16.04.00.00 (I'm in US/Eastern a.k.a. EST5EDT. I don't know what timezone definition cvs is using when I say May 16.) After that, I ran cvs2cl.pl in the Kaffe source dir, which took an *extremely* long time (easily longer than the entire testing process). In fact, it's still not done yet, and it's been running for over 70 minutes. So rather than wait for it, and attempt to get timestamps on the individual check-ins from it, I'm just going to send this message as is. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
[kaffe] (sigh) Kaffe 1.1 can't do FEC decoding
So, after a week of failures every time I tried to download an FEC splitfile from Freenet, using Kaffe 1.1 (or the CVS version from right before the release), I decided that perhaps it's Kaffe that's causing the problem, rather than Freenet. I attempted to download a small FEC splitfile [EMAIL PROTECTED]/music/frank_zappa_-_the_best_band_you_never_heard_in_your_life_-_10_-_mr._green_genes.mp3 (from the Colours site) with two different Freenet builds, using Kaffe 1.1. It failed both times, despite having all the blocks. Then I went back to the early-May Kaffe (and gmp-3.1.1) and the most recent Freenet build I have; I clicked it, took the defaults on the web form, and the operation finished in 37 seconds. I had the file. This message appeared in freenet.log somewhere around the last time my attempt to download that file failed: 12-Jun-03 2:10:27 PM (freenet.node.Node, QThread-636, ERROR): Error while receiv ing message freenet.Message: Accepted @[EMAIL PROTECTED] @ 4b45f 6dd6eacf444 in state freenet.node.states.request.TransferInsertPending: key=2f8f 8c3a9b1468a89dc417aa676dd8fee045b37b110302, hopsToLive=10, id=4b45f6dd6eacf444,f [EMAIL PROTECTED], routedTime=1055441422380: ja va.lang.IllegalStateException: null stream from buffer java.lang.IllegalStateException: null stream from buffer at java.lang.Throwable.fillInStackTrace(Throwable.java:native) at java.lang.Throwable.init(Throwable.java:44) at java.lang.Exception.init(Exception.java:24) at java.lang.RuntimeException.init(RuntimeException.java:21) at java.lang.IllegalStateException.init(IllegalStateException.java:21) at freenet.node.ds.FSDataStoreElement$KeyInputStreamImpl.init(FSDataSt oreElement.java:237) at freenet.node.ds.FSDataStoreElement.getKeyInputStream(FSDataStoreEleme nt.java:46) at freenet.node.ds.FSDataStoreElement$KeyOutputStreamImpl.getKeyInputStr eam(FSDataStoreElement.java:137) at freenet.node.states.data.ReceiveData.getKeyInputStream(ReceiveData.ja va:68) at freenet.node.states.request.InsertPending.relayInsert(InsertPending.j ava:321) at freenet.node.states.request.TransferInsertPending.receivedMessage(Tra nsferInsertPending.java:190) at java.lang.reflect.Method.invoke0(Method.java:native) at java.lang.reflect.Method.invoke(Method.java:255) at freenet.node.State.received(State.java:126) at freenet.node.StateChain.received(StateChain.java:161) at freenet.node.StateChain.received(StateChain.java:52) at freenet.node.StandardMessageHandler$Ticket.run(StandardMessageHandler .java:212) at freenet.node.StandardMessageHandler$Ticket.received(StandardMessageHa ndler.java:159) at freenet.node.StandardMessageHandler$Ticket.access$0(StandardMessageHa ndler.java:line unknown, pc 0x149c471) at freenet.node.StandardMessageHandler.handle(StandardMessageHandler.jav a:68) at freenet.Ticker$Event.run(Ticker.java:229) at freenet.thread.QThreadFactory$QThread.run(QThreadFactory.java:213) 12-Jun-03 2:11:31 PM (freenet.client.http.SFRContext$RequestThread, Thread-3, ER ROR): Finished RequestThread (Forgive me for not sewing the lines back together.) I don't know if this error is directly related to the FEC splitfile errors; but on my system at least, Kaffe 1.1 fails to even *begin* an FEC decode, 100% consistently. (And it leaks memory like an upside-down bucket.) -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] memory leaking
Martin Pohlack ([EMAIL PROTECTED]) wrote: In my recent attempt to build kaffe with the diet libc I noticed some #warnings, given by diet libc: ../kaffevm/.libs/libkaffevm.a(syscalls.o)(.text+0x4e8): In function `jthreadedGetHostByAddr': /home/mp26/erwin/kaffe/kaffe/kaffevm/systems/unix-jthreads/syscalls.c:270: warning: gethostbyaddr() leaks memory. Use gethostbyaddr_r instead! ../kaffevm/.libs/libkaffevm.a(syscalls.o)(.text+0x493): In function `jthreadedGetHostByName': /home/mp26/erwin/kaffe/kaffe/kaffevm/systems/unix-jthreads/syscalls.c:251: warning: gethostbyname() leaks memory. Use gethostbyname_r instead! Maybe diet libc's implementation does. In OpenBSD and most other Unix systems, gethostbyname() uses a static buffer which is returned (or a pointer to which is returned) every time. This means it's not safe to use in multi-threaded apps. Kaffe's aware of this, as you can see by the comments, so they lock the whole thing while it's doing a name lookup. OpenBSD doesn't have the *_r versions. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
[kaffe] make dist-gzip on OpenBSD
'make dist-gzip' on OpenBSD produces several of these: tar: File name too long for tar kaffe-1.1.x-cvs/libraries/javalib/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider tar: File name too long for tar kaffe-1.1.x-cvs/libraries/javalib/org/tritonus/share/sampled/convert/TAsynchronousFilteredAudioInputStream.java ... -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] 1.1.0 build failure on parisc-hpux
Dalibor Topic ([EMAIL PROTECTED]) wrote: Hi, I've tried to build kaffe on HP's TestDrive's parisc-HPUX machine, but I didn't get too far: ln -s ifaddrs.h Usage: ln [-f] [-i] [-s] f1 f2 ln [-f] [-i] [-s] f1 ... fn d1 ifaddrs.h: ifaddrs_compat.h $(LN_S) $ $@ Are you using HP-UX's /usr/bin/make, or GNU make? The former is pretty much rubbish, at least on HP-UX 10.20. I highly recommend installing GNU make before attempting to do any serious work. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] 1.1.0 build failure on parisc-hpux
Additional info: Kaffe builds and installs on HP-UX 10.20 using GNU make and gcc 3.2. (This by itself is pretty astonishing to me; most large projects won't build on this system because they fall over and die when they find out there aren't any pthreads.) The regression tests, however, do not work because they don't compile. ... TestScript[5]: 13020 Bus error(coredump) FAIL: sysdepCallMethod.java error compiling: TestScript[5]: 13045 Bus error(coredump) FAIL: TestNative.java 133 of 137 tests failed Please report to [EMAIL PROTECTED] imadev:/usr/local/src/kaffe-1.1.0$ uname -a HP-UX imadev B.10.20 A 9000/785 2008897791 two-user license imadev:/usr/local/src/kaffe-1.1.0$ file test/regression/core test/regression/core: core file from 'kaffe-bin' - received SIGBUS (gdb) bt #0 0xc4249fb4 in ?? () warning: Attempting to unwind past bad PC 0xc4249fb4 #1 0x7b006128 in ?? () Cannot access memory at address 0x7b03adb8 -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | md.h is already up-to-date In file included from debug.c:1: ../kaffevm/debug.c: In function `kaffe_dprintf': ../kaffevm/debug.c:382: warning: implicit declaration of function `vsnprintf' ClassLoader.c: In function `java_lang_ClassLoader_defineClass0': ClassLoader.c:40: warning: unused variable `iLockRoot' InetAddressImpl.c: In function `java_net_InetAddressImpl_stringToBits': InetAddressImpl.c:107: warning: implicit declaration of function `inet_pton' InetAddressImpl.c: In function `java_net_NativeInetAddressImpl_getHostByAddr0': InetAddressImpl.c:550: warning: implicit declaration of function `inet_ntop' NetworkInterfaceImpl.c: In function `java_net_NetworkInterfaceImpl_getIPAddress': NetworkInterfaceImpl.c:123: warning: implicit declaration of function `inet_ntop' PlainSocketImpl.c: In function `java_net_PlainSocketImpl_socketAccept': PlainSocketImpl.c:276: warning: `remote_addr' might be used uninitialized in this function gra.c: In function `Java_java_awt_Toolkit_graDrawString': gra.c:212: warning: unused variable `n' gra.c: In function `drawAlphaImage': gra.c:669: warning: statement with no effect gra.c:713: warning: statement with no effect gra.c: In function `Java_java_awt_Toolkit_graDrawImage': gra.c:771: warning: statement with no effect gra.c:790: warning: statement with no effect fnt.c: In function `Java_java_awt_Toolkit_fntStringWidth': fnt.c:282: warning: unused variable `n' clr.c: In function `Java_java_awt_Toolkit_clrGetColorModel': clr.c:781: warning: deprecated use of label at end of compound statement jthread.c:158:63: warning: pasting * and sc does not give a valid preprocessing token jthread.c:530:49: warning: pasting * and sc does not give a valid preprocessing token jthread.c:671:51: warning: pasting * and sc does not give a valid preprocessing token gc-mem.c is already up-to-date md.c is already up-to-date In file included from md.c:1: ../../config/parisc/hpux/md.c:12:8: warning: multi-line string literals are deprecated code-analyse.c: In function `analyzeMethod': code-analyse.c:81: warning: concatenation of string literals with __FUNCTION__ is deprecated code-analyse.c:124: warning: concatenation of string literals with __FUNCTION__ is deprecated code-analyse.c: In function `tidyAnalyzeMethod': code-analyse.c:2057: warning: concatenation of string literals with __FUNCTION__ is deprecated debug.c: In function `kaffe_dprintf': debug.c:382: warning: implicit declaration of function `vsnprintf' exception.c: In function `vpostExceptionMessage': exception.c:136: warning: implicit declaration of function `vsnprintf' external.c: In function `loadNativeLibrary2': external.c:277: warning: implicit declaration of function `snprintf' libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: `kaffe-bin' will be relinked during installation check.log.gz Description: application/gunzip pgp0.pgp Description: PGP signature
[kaffe] memory leaking
After having run the CVS release of kaffe, and now version 1.1.0, for several days, I'm pretty sure it's leaking memory a lot faster than the CVS version from a month ago did. The early May version typically took 24 to 48 hours to fill up the memory I allowed it (224 MB) while running Freenet. With the current version, I can reach the limit in just a few hours. From a practical standpoint, this means I have to restart the Freenet node much more frequently. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
[kaffe] assertion !INTS_DISABLED() failed
This was still using the CVS snapshot from Wednesday; I'm updating now, but I figured I'd report it just in case. assertion !INTS_DISABLED() failed: file exception.c, line 398 #0 0x4086327b in kill () #1 0x401fa8bb in abort () #2 0x401b274f in __assert () #3 0x4003a2fc in dispatchException (eobj=0x1e427f8, baseframe=0x3287da8) at exception.c:398 #4 0x4003a594 in floatingException (frame=0x3412dfc) at exception.c:542 #5 0x400898b4 in nullException (sig=11, code=54603372, ctx=0x3412e1c) at signal.c:87 #6 0x4000a004 in ?? () #7 0x4008767f in handleIO (sleep=0) at jthread.c:1861 #8 0x40085732 in handleInterrupt (sig=23, sc=0x0) at jthread.c:693 #9 0x40086337 in jthread_disable_stop () at jthread.c:347 #10 0x4005ddfc in utf8ConstNew (s=0x2128e30 [[B, len=3) at utf8const.c:55 #11 0x4002ff67 in lookupArray (c=0x3cd040, einfo=0x3413984) at classMethod.c:2772 #12 0x40053503 in newArrayChecked (elclass=0x3cd040, count=1, info=0x3413984) at object.c:128 #13 0x40057298 in soft_anewarray (elclass=0x3cd040, size=1) at soft.c:105 #14 0x70aa14 in ?? () #15 0x6fdbe9 in ?? () #16 0x14eb859 in ?? () #17 0x15a1641 in ?? () #18 0x1d4c2ea in ?? () #19 0x12e92d6 in ?? () #20 0x4005c4ae in callMethodV (meth=0x124ec68, func=0x12e9010, obj=0x1, args=0x0, ret=0x0) at ../../config/i386/common.h:38 #21 0x400483e5 in Kaffe_CallVoidMethodV (env=0x40099194, obj=0x3148040, meth=0x124ec68, args=0x3413f94 [EMAIL PROTECTED]@[EMAIL PROTECTED]@) at jni.c:1094 #22 0x40048482 in Kaffe_CallVoidMethod (env=0x40099194, obj=0x3148040, meth=0x124ec68) at jni.c:1107 #23 0x4005d500 in firstStartThread (arg=0x3148040) at thread.c:368 #24 0x400867e8 in start_this_sucker_on_a_new_frame () at jthread.c:1266 #25 0x40086968 in jthread_create (pri=53885632, func=0x400518cf slowUnlockMutex+407, daemon=41776, jlThread=0x0, threadStackSize=19376608) at jthread.c:1336 #26 0x2f5b298 in ?? () #27 0x4001c000 in ?? () -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [freenet-dev] Re: [kaffe] Kaffe and Freenet, round (N+1)
Helmer Krämer ([EMAIL PROTECTED]) wrote: I still doubt that it's working, because that would be too good to be true ;) IIRC, there were some errors that only showed up after freenet was running for a while, right? It still leaks memory, but I've learned to stop worrying about that. Whether it still crashes on assertions, I can't say yet. Even with 1.0.7 I could often run for hours or days between crashes. In the last almost-a-day, I've restarted it twice due to out-of-memory problems, and it hasn't crashed yet. Whether that's good or bad is, I suppose, a matter of taste. I suppose I should test it with a transient Freenet node on Linux, too, just to see if any weird bugs crawl out of it. It won't get the same kind of unpredictable hammering that a permanent node gets, but it's worth a try. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
[kaffe] assertion failed: mem/gc-incremental.c 384
kaffe-bin in malloc(): warning: recursive call. kaffe-bin in malloc(): warning: recursive call. [...] assertion GC_GET_FUNCS(info, idx) sizeof(gcFunctions)/sizeof(gcFunctions[0]) failed: file mem/gc-incremental.c, line 384 #0 0x4086327b in kill () #1 0x401fa8bb in abort () #2 0x401b274f in __assert () #3 0x4003e023 in gcWalkMemory (gcif=0x4009dcd4, mem=0x4009dcfc) at mem/gc-incremental.c:383 #4 0x4003e504 in gcMan (arg=0x4009dcd4) at mem/gc-incremental.c:504 #5 0x4005d2d8 in startSpecialThread (arg=0x3da980) at thread.c:285 #6 0x400867e8 in start_this_sucker_on_a_new_frame () at jthread.c:1266 #7 0x40086968 in jthread_create (pri=11, func=0x4005d2a4 startSpecialThread, daemon=-809510880, jlThread=0x4005cf3d, threadStackSize=1074122447) at jthread.c:1336 #8 0x4005cf1c in createThread (tid=0x3da980, func=0x4005d2a4, stacksize=16384, einfo=0xcfbfd8a0) at thread.c:121 #9 0x4005d3ba in createDaemon (func=0x4003e30c, nm=0x4003f9bb gc, arg=0x4009dcd4, prio=11, stacksize=16384, einfo=0xcfbfd8a0) at thread.c:324 #10 0x4003fa51 in gcEnable (collector=0x4009dcd4) at mem/gc-incremental.c:1093 #11 0x4002a610 in initialiseKaffe () at baseClasses.c:214 #12 0x40044bcb in JNI_CreateJavaVM (vm=0xa340, env=0xa5b8, args=0xa348) at jni.c:205 This is from a CVS checkout on Wednesday evening (CVS/Entries has /ChangeLog/1.1384/Wed Jun 4 23:25:33 2003// as the most recent file.) OpenBSD 3.3 x86, running Freenet 6043. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] current status?
Michael Franz ([EMAIL PROTECTED]) wrote: How long ago was that? I have a pull from cvs that is 2 weeks old and I don't think it works on any classes. There have been major changes to Kaffe in the last two weeks. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [freenet-dev] Re: [kaffe] Kaffe and Freenet, round (N+1)
Toad ([EMAIL PROTECTED]) wrote: On Tue, Jun 03, 2003 at 01:58:58AM +0200, Mark Wielaard wrote: You might want to try to configure kaffe with --enable-pure-java-math that will give you another (the GNU Classpath) java.math.BigInteger implementation (which doesn't use the native libgmp). Eeek. Slw. But I suppose if it's all that works. OK, here we go. I started by updating from OpenBSD 3.2 to 3.3. Then I ran Freenet with Kaffe from early May, which is what I've been using normally with rather good results. This seemed to be OK, just as it was before the OS upgrade. Then I tried building recent CVS Kaffe (I think it's about 2 days old now). I got the same results as before: Negative bit address, whatever that means, whenever I tried to access a document. Then I upgraded gmp from 3.1.1 (the OpenBSD 3.2 port) to 4.1.1 (the 3.3 port). I rebuilt Kaffe with that version of gmp, and still got the same results: Negative bit address. Next, I tried with --enable-pure-java-math. This seemed to be working better; I could run the node and retrieve documents via fproxy (the web interface) without Negative bit address errors. But, as Toad said, it's incredibly slow compared to gmp. Running top, I saw kaffe-bin take about 30-40% (with spikes up to 90%) of the CPU when I hit a few image-heavy pages. Normally I don't see it get over 50% even when it's doing FEC decoding -- under normal conditions, like retrieving a few pages of images, it never got over 20% or so. Then, after about 1:30 of CPU time, the node went into a comatose state. I see this fairly often even with the early-May Kaffe; the node just sits there, not eating any CPU; sometimes it pulls out by itself after a few *minutes*(!), but usually it's time to restart it. After waiting about 5 minutes, I restarted it. Meanwhile, stdout/stderr had this: kaffe-bin in malloc(): warning: recursive call. kaffe-bin in malloc(): warning: recursive call. kaffe-bin in malloc(): warning: recursive call. And freenet.log had this: 03-Jun-03 10:42:16 PM (freenet.interfaces.PublicInterface, Interface # tcp/36963, NORMAL): Getting thread to dispatch in PublicInterface took more than 10 seconds! If this happens frequently, report it to [EMAIL PROTECTED] Waited 101231 millis. java.lang.Exception: debug at java.lang.Throwable.fillInStackTrace(Throwable.java:native) at java.lang.Throwable.init(Throwable.java:44) at java.lang.Exception.init(Exception.java:24) at freenet.interfaces.PublicInterface.dispatch(PublicInterface.java:109) at freenet.interfaces.Interface.acceptConnections(Interface.java:220) at freenet.interfaces.Interface.run(Interface.java:172) at java.lang.Thread.run(Thread.java:334) (This occurred several times.) Pretty soon, the restarted node had ground itself down into a coma just like the first time. top showed the CPU usage had dropped to nothing, with about 1:33 elapsed CPU. No more images were coming through on the web interface. There weren't any messages in the logs this time, though. So, the upshot is, I'm still running early-May CVS Kaffe. It's the only thing that still works. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] build failure if old version present, ServletContext.setAttribute
Dalibor Topic ([EMAIL PROTECTED]) wrote: assertion blk-free != 0 failed: file mem/gc-mem.c, line 324 Does running with -vmdebug GCDIAG help to provoke it faster? I had to rebuild with --enable-debug $ time java -vmdebug GCDIAG freenet.node.Main assertion gc_heap_isobject(info, unit) failed: file mem/gc-incremental.c, line 259 Abort (core dumped) 1.91s real 1.73s user 0.12s system $ time java freenet.node.Main Illegal instruction (core dumped) 97.39s real35.61s user 2.57s system Here's the core dump backtrace for the second one: #0 0x401cb0bd in getaddrinfo () #1 0x401cb5fd in getaddrinfo () #2 0x401cb3a9 in getaddrinfo () #3 0x401ca9fb in getaddrinfo () #4 0x401c9a58 in getaddrinfo () #5 0x401c98d3 in getaddrinfo () #6 0x407e8543 in java_net_NativeInetAddressImpl_lookupAllHostAddr0 ( none=0x417ff0, jStr=0x25f4dc8) at InetAddressImpl.c:160 #7 0x46323d in ?? () #8 0x43855b in ?? () #9 0x466218 in ?? () #10 0x465239 in ?? () #11 0x1502471 in ?? () #12 0xa5d641 in ?? () #13 0x22a12ea in ?? () #14 0xab22d6 in ?? () #15 0x400591a2 in callMethodV (meth=0xa31880, func=0xab2010, obj=0x1a98c20, args=0x1e0df94 [EMAIL PROTECTED]@[EMAIL PROTECTED]@¼¼\t@, ret=0x1e0dbec) at ../../config/i386/common.h:38 #16 0x400452d5 in Kaffe_CallVoidMethodV (env=0x4009617c, obj=0x1a98c20, meth=0xa31880, args=0x1e0df94 [EMAIL PROTECTED]@[EMAIL PROTECTED]@¼¼\t@) at jni.c:1094 #17 0x40045372 in Kaffe_CallVoidMethod (env=0x4009617c, obj=0x1a98c20, meth=0xa31880) at jni.c:1107 #18 0x4005a17c in firstStartThread (arg=0x1a98c20) at thread.c:357 #19 0x40083394 in start_this_sucker_on_a_new_frame () at jthread.c:1266 #20 0x40083514 in jthread_create (pri=596, func=0, daemon=1000, jlThread=0x196f960, threadStackSize=0) at jthread.c:1336 So I ran it again: $ time java freenet.node.Main assertion !INTS_DISABLED() failed: file exception.c, line 398 Abort (core dumped) 66.19s real32.22s user 2.16s system #0 0x401f327b in kill () #1 0x401f2bd7 in abort () #2 0x401adf53 in __assert () #3 0x400372fc in dispatchException (eobj=0x1f0d638, baseframe=0x19d1e98) at exception.c:398 #4 0x40037594 in floatingException (frame=0x1c8e38) at exception.c:542 #5 0x4008642c in nullException (sig=11, code=1871528, ctx=0x1c8e58) at signal.c:87 #6 0x40009004 in ?? () #7 0x40059f50 in startSpecialThread (arg=0x1a34b0) at thread.c:274 #8 0x40083394 in start_this_sucker_on_a_new_frame () at jthread.c:1266 #9 0x40083514 in jthread_create (pri=11, func=0x40059f1c startSpecialThread, daemon=-809511144, jlThread=0x40059c19, threadStackSize=1074109355) at jthread.c:1336 #10 0x40059bf8 in createThread (tid=0x1a34b0, func=0x40059f1c, stacksize=16384, einfo=0xcfbfd798) at thread.c:121 #11 0x4005a032 in createDaemon (func=0x4003b23c, nm=0x4003c8eb gc, arg=0x4009acac, prio=11, stacksize=16384, einfo=0xcfbfd798) at thread.c:313 #12 0x4003c981 in gcEnable (collector=0x4009acac) at mem/gc-incremental.c:1093 #13 0x40027610 in initialiseKaffe () at baseClasses.c:214 #14 0x40041abb in JNI_CreateJavaVM (vm=0x9310, env=0x9488, args=0x9318) at jni.c:205 Good luck. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] Compare kaffe and IBMJava2-131 Java Virtual Machine.
Dalibor Topic ([EMAIL PROTECTED]) wrote: Could you rebuild kaffe with debugging enabled, and run it with kaffe -vmdebug GCSTAT,GCDIAG -verbosegc -verbosemem your-class 2gc-stats.txt http://wooledge.org/~greg/gc-stats.txt.bz2 (83kB) I started up Freenet with those switches (without my normal -mx 224M) and then beat upon it vigorously with local requests. You may notice that at one point, an OutOfMemoryError is also printed. This appears to have come from Freenet's stderr: java.lang.OutOfMemoryError at freenet.thread.QThreadFactory$QThread.run(QThreadFactory.java:218) I don't know whether it's relevant. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] Compare kaffe and IBMJava2-131 Java Virtual Machine.
Dalibor Topic ([EMAIL PROTECTED]) wrote: I assume that the Freenet developers lurking on this mailing have some experience with respect to scalability of kaffe on their platforms, as they use kaffe with a) tons of threads b) to run crypto code c) lots of network activity Matthew, Greg, could you provide some anectodes/numbers? Matthew is a Freenet developer; I'm a user, documentation writer, and unofficial tech support helper. I'm using Kaffe to run Freenet on OpenBSD because, as far as I know, there is no other usable Java virtual machine for OpenBSD. The Linux x86 Java binaries from Sun will run, to a certain extent, but they did not work for me when running Freenet. (The Linux emulation layer is obviously not 100% complete/bug-free. The major symptom was that reads from a socket that didn't already have data waiting didn't block as they were supposed to; they returned without any data. Since Freenet is supposed to provide network services, this made it unusable.) I'm configuring Kaffe with ./configure --with-includes=/usr/local/include --with-libraries=/usr/local/lib --with-engine=jit3. I also have to edit the libtool file by hand after the configuration, to change need_version from no to yes. Apart from this, it compiles and installs cleanly. I have two problems with Freenet under Kaffe: crashing and memory usage. I've posted gdb stack traces of Kaffe core dumps to this mailing list already. Since the FD_ISSET assertion (jthread.c:1750) was removed from CVS recently, I no longer get that particular one; but I'm still getting this one occasionally: assertion !INTS_DISABLED() failed: file exception.c, line 398 However, I'm getting dramatically *fewer* crashes with CVS Kaffe than I did when I started using Kaffe (1.0.7). (It's also worth mentioning that Kaffe 1.0.6 and earlier will not work with Freenet at all. The OpenBSD Kaffe port is still 1.0.6, and therefore less than useful for me.) In terms of memory usage, a long-running Freenet node creeps continually upward. I've got the ulimits set so that Freenet cannot exceed 256 MB of memory, and I'm running the java command with -mx 224M. After a few days, it will hit this limit (if it doesn't crash first). It's not supposed to do that; Linux users report that Freenet's memory usage under Sun's Java VM remains steady at something like 30 MB (depending on which build of Freenet is being used, which version of the Java VM, etc.). Apart from these two issues, Freenet runs quite well under Kaffe for me. Performance is extremely difficult to measure with Freenet because the amount of work being done by a live node is unpredictable. Data requests from other nodes could occur at any time. The single most intensive operation the node performs, at least from the end user's perspective, is encoding/decoding large files with FEC (Forward Error Correction). Large files in Freenet are broken into segments with a maximum size of 128 MB. Each segment consists of 128 or fewer data blocks, and a number of check blocks (currently 50% of the data blocks, so a maximum of 64). Retrieving any 128 of these 192 blocks is sufficient to reconstitute the whole segment, but decoding the 128 MB segment can take several minutes. On my 1300 MHz Duron, it's a bit over 2 minutes, wall-clock time, but this can be deceptive because the node is not idle during this operation; it's still processing other requests. (It's also not entirely CPU-bound; there is a considerable amount of disk activity associated with this, writing the blocks to temporary files during the fetching, reading them back in during the decoding, and writing the reconstituted segments out to the final destination.) I'm using the Java FEC library that's supplied with Freenet. There is also supposed to be a native x86 FEC library, but I have not tried it. I'm not even sure what the compatibility requirements are. Since I can't run Freenet under Linux on this machine to give numbers which would be useful for comparison purposes, all I can say is that I'm pleased with Kaffe's performance under heavy loads. On a side note, is there a FreenetMark ? There is (or was) a simulator which fired up several Freenet nodes on a single machine in order to test the networking protocols, routing, and so on. I don't think it was designed to measure performance; but rather, correctness and scalability of the Freenet code and heuristics. The Freenet developers might have more information about it; it was mentioned recently on the Freenet development list. (The thread started here: http://hawk.freenetproject.org:8080/pipermail/devl/2003-February/004408.html and continued here: http://hawk.freenetproject.org:8080/pipermail/devl/2003-March/004415.html It seems that the mailing list archives can't handle threads that span an end-of-month boundary.) -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org
Re: [kaffe] networkaddress.cache.ttl
Dalibor Topic ([EMAIL PROTECTED]) wrote: InetAddress caching shouldn't be that hard to add, though, if you'd like to submit a patch. Hehe... no, Matthew left out the context for his question. He's maintaining Freenet (freenetproject.org), and the caching of old DNS lookup data by the Sun JVM is causing some problems for users with dynamic DNS hostnames. He wants to turn caching *off*! :) -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] 6 failed dependencies
cal kaiwen ([EMAIL PROTECTED]) wrote: I tried to compile kaffe on Linux machine, and I got the following errors. [root@users Users]# rpm -ivh kaffe-1.0.5-6.i386.rpm That's not compiling. That's installing an RPM. error: failed dependencies: libICE.so.6 is needed by kaffe-1.0.5-6 libSM.so.6 is needed by kaffe-1.0.5-6 libX11.so.6 is needed by kaffe-1.0.5-6 libXext.so.6 is needed by kaffe-1.0.5-6 libjpeg.so.62 is needed by kaffe-1.0.5-6 libpng.so.2 is needed by kaffe-1.0.5-6 libungif.so.4 is needed by kaffe-1.0.5-6 You're missing X11, jpeg, PNG and (un)GIF libraries. Or you may have them, but the wrong versions. As mentioned previously, Kaffe 1.0.5 is rather old. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | msg01431/pgp0.pgp Description: PGP signature
Re: [kaffe] Upgrading autotools requirements to a more recent version
gonzo ([EMAIL PROTECTED]) wrote: i'm using autoconf 2.13 and automake 1.4p6 on Debian/unstable. i do have autoconf2.50 on my box, though the command autoconf refers to 2.13 by default. Current Debian unstable uses autoconf 2.57. Prior to this, Debian had both autoconf 2.13 and 2.5x simultaneously. /usr/bin/autoconf was a wrapper script which would invoke autoconf2.5x if a configure.ac file existed in `pwd`, or autoconf2.13 otherwise. This is true even in woody (Debian 3.0), so it's been that way for a fairly long time. Try this: cd /tmp touch configure.ac autoconf --version -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | msg01356/pgp0.pgp Description: PGP signature
Re: [kaffe] core dump, assertion failed (FD_ISSET)
Greg Wooledge ([EMAIL PROTECTED]) wrote: assertion FD_ISSET(i, readsPending) failed: file jthread.c, line 1750 Just FYI, I've seen this assertion a total of 5 times now, running with the jit3 engine, to the exclusion of the other two assertions I saw earlier (under the intrp engine). I haven't saved any of the other cores (they're quite large); but I'm sure there will be plenty more of them should the need arise. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | msg01303/pgp0.pgp Description: PGP signature
[kaffe] core dump, assertion failed (THREAD_RUNNING)
) at ../kaffe.def:2696 #38 0x40053f2e in virtualMachine (meth=0x354b3f8, arg=0x9f688b8, retval=0x9f68bb4, tid=0x3e47360) at machine.c:231 #39 0x40056212 in runVirtualMachine (meth=0x7808e0, lcl=0x9f6, sp=0x9f688a0, npc=139, retval=0x9f68bb4, mjbuf=0x9f68930, tid=0x3e47360) at ../kaffe.def:2594 #40 0x40053f2e in virtualMachine (meth=0x7808e0, arg=0x9f68ac0, retval=0x9f68bb4, tid=0x3e47360) at machine.c:231 #41 0x40056aa1 in runVirtualMachine (meth=0x3567c68, lcl=0x9f68a78, sp=0x9f68ab0, npc=73, retval=0x9f68bb4, mjbuf=0x9f68b30, tid=0x3e47360) at ../kaffe.def:2753 #42 0x40053f2e in virtualMachine (meth=0x3567c68, arg=0x9f68c10, retval=0x9f68bb4, tid=0x3e47360) at machine.c:231 #43 0x4004ca90 in callMethodV (meth=0x3567c68, func=0x3567c68, obj=0x3e47360, args=0x9f68f94 ÏÔ\004@`0\006@¸¡\001@ø\232\006@, ret=0x9f68bb4) at support.c:754 #44 0x4003dd55 in Kaffe_CallVoidMethodV (env=0x4006416c, obj=0x3e47360, meth=0x3567c68, args=0x9f68f94 ÏÔ\004@`0\006@¸¡\001@ø\232\006@) at jni.c:1094 #45 0x4003ddcf in Kaffe_CallVoidMethod (env=0x4006416c, obj=0x3e47360, meth=0x3567c68) at jni.c:1107 #46 0x4004da1b in firstStartThread (arg=0x3e47360) at thread.c:357 #47 0x40058924 in start_this_sucker_on_a_new_frame () at jthread.c:1252 #48 0x40058a42 in jthread_create (pri=59592068, func=0x40057dab suspendOnQThread+207, daemon=1074147424, jlThread=0x0, threadStackSize=3070320) at jthread.c:1322 #49 0x38c6010 in ?? () I still have the core file if anyone wants me to attempt a more hands-on analysis. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | msg01273/pgp0.pgp Description: PGP signature
Re: [kaffe] Failed to locate native function: java/math/BigInteger.init0()V
Dalibor Topic ([EMAIL PROTECTED]) wrote: It probably means that the configure script is unable to pick up gmp and something really bad happens ;) Yes; I worked around this by creating symlinks to the gmp header and library files from /usr/include and /usr/lib respectively. I couldn't find anything like --with-gmp=/usr/local in the configure script's --help. On a side note, I'd like to replace the GMP based java.math. code by the pure java implementation from GNU Classpath. I'm running benchmarks tonight to see what the eventual outcome would be like. This would probably hurt people using kaffe in interpreter mode for crypto software, or using java.security features. Is there anybody out there doing that? Freenet makes extremely heavy use of cryptographic code. I'm currently running in interpreter mode because you guys suggested it as a possible way to avoid certain assertions -- but see my previous message for the first assertion. :-/ -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | msg01274/pgp0.pgp Description: PGP signature
Re: [kaffe] [crash] Jython 2.1 Installer vs. jthread_disable_stop
Dalibor Topic ([EMAIL PROTECTED]) wrote: Could you guys check if you still get them using the latest source from CVS when you configure kaffe --with-engine=intrp ? OpenBSD 3.2 i386 ./configure --with-engine=intrp gmake (cd .libs gcc -c -fno-builtin -fno-rtti -fno-exceptions kaffe-binS.c) rm -f .libs/kaffe-binS.c .libs/kaffe-bin.nm .libs/kaffe-bin.nmS .libs/kaffe-bin.nmT gcc -g -O2 -Wall -Wstrict-prototypes -o .libs/kaffe-bin main.o version.o .libs/kaffe-binS.o -L../kaffevm/.libs -lkaffevm -L/usr/local/lib -lm ../../libltdl/.libs/libltdlc.al -Wl,-rpath,/usr/local/kaffe/jre/lib/i386 -Wl,-rpath,/usr/local/lib ld: -lkaffevm: no match collect2: ld returned 1 exit status gmake[2]: *** [kaffe-bin] Error 1 gmake[2]: Leaving directory `/usr/local/src/kaffe/kaffe/kaffe' This is the same build failure I reported back in August 2002. At the time, the suggested workaround (from Arne and Dalibor) was: I added the following lines after lines 132 in the current readonly CVS kaffe/libtool: if test X`uname` = XOpenBSD; then need_version=yes fi This still works, although the number 132 is now a bit too low. :) It's going to be a while until I can report anything on the assertions, of course -- even with 1.0.7 they sometimes take a day or two to appear. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | msg01230/pgp0.pgp Description: PGP signature
