Re: JVM and threads
On Tue, Sep 03, 2002 at 10:03:15PM +0200, Marco Trevisan wrote: > I found out that the best performing JVM on a single-processor Linux > machine is Blackdown-1.3.1 with green threads and the OpenJIT compiler. > Other JVMs I tried are: IBM v1.3.0 - 1.3.1, Sun v1.3.1 - 1.4.x If there is any gain in speed it's most likely because of the context switching overhead of native threading (crossing kernel trap boundaries) verses green threading which runs within userspace (fast context switching). > It was a surprise for me to find out such a result, infact some > benchmark classes I've done in order to measure pure processing power > showed the IBM JDK as the best performer: nevertheless, when it comes to > running my webapp under Tomcat, Blackdown 1.3.1 with green threads and > OpenJIT makes it run _noticeably_ faster. OpenJIT is good stuff. :) > I looked at the NGPT home page, surfed the net and found some > interesting benchmarks : > http://www.opengroup.org/rtforum/jan2002/slides/linux/abt.pdf . There purpose is to build a highly scalable and complete pthreads system. LinuxThreads is missing a couple of things that are important to the Posix specification, namely proper signal handling. The HotSpot compiler code accounts for this brokeness with another signal handling layer within the internal thread management code... That's got to be addressed in the code before the threading system can run. > At http://www.ibm.com/developerworks/oss/pthreads/, they say: "This > release is fully suitable as a replacement for LinuxThreads by either a > single user or group or an entire distribution." > Does it mean that if I patch the kernel and install it on my system, my > JVM will use it? I guess it's not so easy :-) I believe what I've said to be accurate, but... If it emulates all the bad signal handling in Linux, then it might work. You can try it and report back to us. :) bill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM and threads
On Wed, Sep 04, 2002 at 10:30:46AM +0200, Ingo Rockel wrote: > I just had a look at the mail-archive of their mailing-list. There is a > statement clarifying, their stuff will NOT work with current JVMs. > > Look here: > http://www-124.ibm.com/pipermail/pthreads-users/2002-August/000250.html > > It seems also Sun will not support NGPT anytime soon, as they focus on > IA-64 at the moment. IBM is working on JVM which will work with NGPT. Yeah, then one route in getting that kind support going under Linux is for them to get enough Posix conformance in NGPT system, so that the Solaris threading implementation can be used in place of the LinuxThreads infrastructure. This is what was basically done in the FreeBSD port recently so you folks should be able to get some simple patches to get a head start for porting to NGPT. LinuxThreads is terribly anyways, so it's probably a good thing to get rid of it. A good M:N threading system should be able to get you green threads like context switch performance while the IO system is back by a kernel threading entity... FreeBSD's libc_r (Posix threading) is basically a kind of green threading for those that don't know... ;) bill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM and threads
On Wed, Sep 04, 2002 at 07:59:30AM -0700, Dan Kegel wrote: > As I wrote in a previous message, Sun is abandoning M:N threading; > see http://java.sun.com/docs/hotspot/threads/threads.html > NGPT is probably a dead end. I suspect Gnu and Linux will continue > on with kernel-based threads, but with radical changes for the > 2.6 kernel release to improve performance and POSIX compliance. All it really needs is some kind of shared signal handling for their light weight threading model to get much better Posix signal conformance. I'm a bit skeptical about the other stuff. Not sure why anybody would use futexes, etc... I'd normally expect that stuff to be best done by a userspace threading system mainly because of speed. To get around the M:N/1:1 problems, the FreeBSD folks are working on KSE's (kernel scheduler entities) which is a kind of scheduler activations model with upcalls from the kernel to communicate the status of kernel light weight process to the userspace threading system that backs the corresponding userspace thread. But that's all pretty experimental at this time. NetBSD seems to have made much more progress with this. Not sure how this is all going to play out since there's a lot of design tradeoffs in building these kind of threading system. > There has been no announcement of the pthreads replacement, but > see e.g. > http://marc.theaimsgroup.com/?l=linux-kernel&m=102949331625369&w=2 > http://marc.theaimsgroup.com/?l=linux-kernel&m=102926595920544&w=2 > http://people.redhat.com/mingo/tls-patches/ > http://marc.theaimsgroup.com/?l=linux-kernel&m=102961013307169&w=2 > etc. for an idea of what's going on. bill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM and threads
On Wed, Sep 04, 2002 at 08:41:07AM -0700, Dan Kegel wrote: > You're referring to Linuxthreads? It has a couple other problems, > like pid being different for each thread, and thread startup and > shutdown > not being as fast as thread maniacs (you know, the people who create > more than 1 thread/second) would like. Yeah, LinuxThreads...but don't really consider the pid issue nearly as serious as signal delivery. > Futexes are for speed. They let you do mutexes mostly in userspace > even though you're using a kernel theading system. Yeah, I know that. What about context switching overhead ? I would expect a userspace system to still be substantially faster than anything kernel bound. > M:N threading systems and userspace threading libraries add a noticable > amount of complexity, but historically have had a speed advantage over > plain old kernel-provided threads. Linux is working hard on getting > rid of the speed disadvantage of kernel-provided threads (using things > like futexes to move the fast path to userspace). > It's an interesting race. I bet you a nickel Linux's approach will > win in the end (Occam's Razor and all that). Well, er... maybe. We'll see. ;) bill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM and threads
On Wed, Sep 04, 2002 at 09:28:37AM -0700, Dan Kegel wrote: > I have no idea what Ulrich is planning for his linuxthread replacement, > but once it's out in the open, we can probably finally fix issues > like signal delivery. Is there some public docs on this project ? I'm out of the loop as far as the Linux community goes in this area. ;) > Linux has been doing a pretty good job at keeping context switching > overhead low. The proof will be in the pudding -- say, in scores So has NetBSD. lmbench is within 2x of Linux and they're working SAs at this moment. They seem to have the best chance at getting a good threading model to happen in any BSD right now. The FreeBSD effort is much more ambitious technically and it's being done without any fulltime engineers. > on the Volanomark benchmark (or some better threading benchmark) on an > SMP system. ...A better threading benchmark... The JVM doesn't have the most direct threading subsystem glue code to the native API, so that could effect performance measurements. > My wager stands :-) I'm not a betting person. I think it's a disgusting habit. ;) Well, Linux is a couple of things working against it, namely a UTS (userspace threading system) can schedule a thread within 2 context switches and a call to the scheduler function when it encounters a sleep operation (via mutex block, sleep or blocking IO). Linux with clone() must cross a protected domain to block and reschedule which adds additional overhead that neither green threads nor FreeBSD's libc_r has. That's going to be a tough combination to beat and you've got to admit that, right ? ;) FPU/exception issues might make things more bizzare since architectural specific details vary across CPUs (brain dead x86) alter the time window balance between exception handling that crosses a protection domain, verses context switching. I'm not a low level CPU person per se, so I don't have answers nor any hints to what the answers would be in these cases. That's all. The proof is in the pudding or so they say. ;) bill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: per jvm thread limit
On Fri, Feb 14, 2003 at 04:22:31PM -0800, John Neffenger wrote: > Further note to readers: I got past this 16,000 native thread limit by > specifying the "-green" user-level thread option to the Blackdown > virtual machine. So my 20,000 threads were all mapped onto one Linux > process (one Linux native thread). That's nuts. :) > I'm eager to find out what kind of socket and thread limits we'll hit > when we test the Java 1.4 new I/O implementations on Windows, Solaris, > Linux, and FreeBSD. My guess is that it'll probably be limited by the OS itself. FreeBSD doesn't have KSEs just yet, which will limit their SMP scalability severely. They have kqueue which is heavier than Linux's epoll, but should give it a solid scalability advantage over most Unixes that only have select()/poll() even without strong SMP and threading. FreeBSD's libc_r pthread layer is pretty much a kind of green threading in that everything, context switching and conditional variable handling, is done in userspace. It's not going to scale well since it converts blocking IO calls into async wrapper that poll() manages. Nobody has done the work for converting that into a kqueue call. Read: http://www.aims.com.au/chris/kse/docbook Linux has new stuff in the works, in the form of their new threading model and epoll, that has yet to be integrated into HotSpot and I'd imagine that have likely impact on performance, context switching, etc... That needs to be taken into mind when writing the article. Safepointing performance might be problematic in a system like that. Don't know yet until it gets integrated. Don't know about Windows, they have an async IO facility and 1:1 threading. > Our next Volano Report will have results up to 10,000 connections using > the "old I/O" -- a place where, so far in our tests, only Blackdown and > BEA JRockit can go. There may be some options, that I just recently > discovered, which we can use to get Sun's HotSpot Server VM on Solaris > there, too: > > http://java.sun.com/docs/hotspot/PerformanceFAQ.html#5 > > Java and Solaris Threading > http://java.sun.com/docs/hotspot/threads/threads.html I'd imagine the limits of those two runtimes are limited by how well they take advantage of native OS facilities. If they're using legacy stuff like select(), then it'll hurt badly. If they take advantage of scalable OS facilities, well... :) bill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Volano Report update
On Tue, Jun 03, 2003 at 11:49:28AM +0200, Marco Trevisan wrote: > In my opinion: > > - you tested Blackdown-1.3.1 using green threads, but Sun JVM used > native threads. In Linux this makes a huge difference in terms of thread > scalability with one CPU. It should be useful to show the Linux Sun > 1.3.1 JVM results with -green option. Also, 2.5.x Linux has changes to their 1:1 model that greatly increases scalability for dealing with a large number of threads. bill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Volano Report update
On Tue, Jun 03, 2003 at 10:57:46PM -0700, John Neffenger wrote: > Hi Juergen, > Do you mean that the Sun and Blackdown native-thread HotSpot Server VMs > will be able to go right up to 10,000 connections (about 20,000 threads) > right out of the box on Red Hat Linux 9? (On Red Hat Linux 8.0, they > both fail miserably just over 1,000 connections.) I've downloaded the > Red Hat installation CD-ROMs, but I didn't think it was worth even > trying it yet, figuring I had to wait for Java 1.5 or later for the > vendors to support it. > > If Java and NPTL are working together already, that changes everything. > Just when I thought I was done testing for a while ... The kind of things in the next Linux kernel are pretty neat, but folks using LinuxThreads should also see a performance impact from the recent optimization concerning pid lookup in Linux. If I remember correctly, they use to do a lot of linear scanning, but now this is replaced by hashed/dictionary operations. Cond-var performance is a totally different issue, but the next version of Linux (2.6) should rock for thread creation/destruction and other things like that since 1:1 threading is more directly supported in the kernel instead of being a coarse hack. The next version of Linux is looking might nice. The current development version that I'm using runs very smoothly (2.5.70-mm1). There's enough that's going on with the next threading system (I forget the name, it's too confusing) that things like getting at the ucontext of a suspended thread and things like that can be directly support by the Linux kernel specifically for the Sun's JVM and other language runtimes. It's simple enough to do so since the framework for thread suspension can be added in easily, from what I see, and other things concerning garbage collection. All of that threading stuff is much more well structured now. Previously, you wouldn't entertain this possibity since LinuxThreads was so horrible. That's my take on it. :) bill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is 1.3.1-02d-FCS version of JRE???
On Mon, Apr 19, 2004 at 02:47:56PM -0400, Kevin B. Hendricks wrote: > Since the Blackdown PPC Linux project was so small and I had such a hard time > finding anyone to help it along, I finally just pretty much gave up. I have > only done the barest minimum to keep the Blackdown JDK 1.3.1 functioning (it > has no hotspot or JIT). I simply can not compete with IBM's JDK 1.4.X with > fancy JIT available for both Linux ppc 32 and ppc64. > > I do know there are some people still interested in PPC Linux support so they > may have something interesting to add. The HotSpot JIT backend is a monster as well as the entire compiler/runtime on many fronts. It's not trivial to interpret Sun's compiler intermediate representation and have it output something sensible with proper register allocation, etc... But regardless, I and mostly likely others thanks you for your effort, and I personally sympathize with your suffering. :) bill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Joseph Shraibman wrote: Thread.yield() is used under two different scenarios: + waiting for certain condition to become true (or false), most likely this is used in a yield loop, and current thread has nothing to do but burning CPU cycles in a while loop. + be nice and let kernel/pthread know that this would be a good point to schedule another thread to run, current thread still has some work to do. Such yields are necessary for non-preemptive schedulers (e.g. green thread). In the first case, it's probably OK to sleep(1), but it makes no sense for the second case. Uh, sure, forcing yourself to sleep means another thread will be scheduled. They don't really want to be kicked out of CPU. But you have to have those yield()'s inserted into a program because otherwise the program would not work with, say, green threads. For example, you need to place yields in computational loops to voluntarily give up execution so it won't occupy all CPU cycles and block other threads. The yields are convenient points for scheduler to kick in, but the thread has useful stuffs to do if it's kept in CPU a little longer. When the same program is running with native threads, it's more efficient if such yields are considered as nops, since context switchings are expensive and scheduler is now able to switch threads at any point. Sleep(1) is even worse in this case because it leaves CPU idle when it can do useful work. (did I mention sleep(1) can actually take 10ms, because of clock granularity?) That being said, by default Sun's JDK converts Thread.yield() directly to sched_yield() on Linux. Kernel scheduler will decide whether or not to actually switch context. -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Joseph Shraibman wrote: Alexander V. Konstantinou wrote: Actually, thread priorities work fine in Linux. No, they don't, not with the latest sun jdk on redhat 8.0. Thread priority is just a hint (same applies to Thread.yield()). It's up to the underlying system (in this case, the Linux kernel scheduler) to decide whether or not to honor thread priorities. On Linux, threads are cloned processes and are scheduled in the kernel space. JDK passes the priority information to the kernel, but they are ignored. It may sound like a surprise, but most of the time kernel scheduler can do a better job than human in prioritizing jobs. After all, only kernel scheduler knows how threads interact with each other and/or with other applications. -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Joseph Shraibman wrote: Hui Huang wrote: Joseph Shraibman wrote: Alexander V. Konstantinou wrote: Actually, thread priorities work fine in Linux. No, they don't, not with the latest sun jdk on redhat 8.0. Thread priority is just a hint (same applies to Thread.yield()). While the jvm authors can't do anything about the kernel ignoring the priority, they *can* do something about Thread.yield(): make it the equivalent to sleep(1) No. sleep(0) would come close, not sleep(1). Thread.yield() is used under two different scenarios: + waiting for certain condition to become true (or false), most likely this is used in a yield loop, and current thread has nothing to do but burning CPU cycles in a while loop. + be nice and let kernel/pthread know that this would be a good point to schedule another thread to run, current thread still has some work to do. Such yields are necessary for non-preemptive schedulers (e.g. green thread). In the first case, it's probably OK to sleep(1), but it makes no sense for the second case. And you can always sleep on a monitor instead in the first case, it's better than yield. sleep(0) is acceptable for both cases, but again with sleep(0), it's up to the scheduler to decide if or not to actually switch context. kernel space. JDK passes the priority information to the kernel, How? pthread_setschedparam. Note that sched_priority is ignored under SCHED_OTHER policy. but they are ignored. It may sound like a surprise, but most of the time kernel scheduler can do a better job than human in prioritizing jobs. Um, no. The few cases I would set a priority I would have a good reason. BTW does the jvm give threads with higher prio prefrence when delivering notify()'s? No, IIRC. -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: per jvm thread limit
Joseph Shraibman wrote: Juergen Kreileder wrote: [EMAIL PROTECTED] writes: On Fri, 14 Feb 2003, Juergen Kreileder wrote: BTW: If you use another setting than CONFIG_1GB or if you're on x86-64 you want to use the new release. Older HotSpot versions have problems with the other values. So which ones are good? Is the latest sun jdk good or only the forthcoming blackdown? Blackdown 1.4.1-01 (released yesterday) works correctly. AFAIK Sun will fix the problem in 1.4.2. Do you know if sun fixed in in 1.4.1_02? No. The change has not been backported. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Volano Report update
Christopher Smith wrote: On Tue, 2003-06-03 at 19:29, John Neffenger wrote: Hi Bill, Also, 2.5.x Linux has changes to their 1:1 model that greatly increases scalability for dealing with a large number of threads. I was under the impression that Java application developers will have to wait for the Java virtual machines to take advantage of those threading changes before we see any benefits. I read that IBM needs to make changes in their Java VM on Linux to support it, for example. Is that correct? That is my understanding right now. The latest JVM's from Sun and IBM apparently take steps to disable NPTL. I'm not if anyone working on the blackdown project is planning to get support for NPTL in ahead of Sun or IBM. No, that's not true. Both JDK 1.4.1 and 1.4.2 from Sun support NPTL. You can compare NPTL and LinuxThreads easily by running on RH-9 and setting LD_ASSUME_KERNEL to different values (see Redhat release notes). If you plan to run volano, don't forget to apply the latest glibc patch, it fixed a condvar bug that could hang volano. I've heard reports that 1.3.1 is OK too, but we didn't test it. Blackdown version works fine too. regards, -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Volano Report update
John Neffenger wrote: Hi Bill, Also, 2.5.x Linux has changes to their 1:1 model that greatly increases scalability for dealing with a large number of threads. I was under the impression that Java application developers will have to wait for the Java virtual machines to take advantage of those threading changes before we see any benefits. In 1.4.1 & 1.4.2, we didn't do any NPTL-specific optimization (read: no non-portable stuff that is based NPTL implemention). But the advantage of the new threading library is still easy to see. The easiest example is that you can create more than 1000 threads now, as NPTL no longer has the 1024 hard limit on max number of threads. We don't have any hard limit within JVM either. So running Sun JDK (or blackdown's) on NPTL will likely give you different results in section 3, network scalability. There are other improvements too. Some (e.g. faster mutex) may help Java applications, others (e.g. better signal handling) could be hardly noticeable unless you have JNI code. regards, -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Volano Report update
Christopher Smith wrote: Juergen Kreileder wrote: Christopher Smith <[EMAIL PROTECTED]> writes: On Tue, 2003-06-03 at 19:29, John Neffenger wrote: Hi Bill, Also, 2.5.x Linux has changes to their 1:1 model that greatly increases scalability for dealing with a large number of threads. I was under the impression that Java application developers will have to wait for the Java virtual machines to take advantage of those threading changes before we see any benefits. I read that IBM needs to make changes in their Java VM on Linux to support it, for example. Is that correct? That is my understanding right now. The latest JVM's from Sun and IBM apparently take steps to disable NPTL. Huh? RH 9 already uses NPTL, Sun and Blackdown JVMs work on it. (I don't know about IBM's.) To clarify: yes, RH9 has NPTL. However, NPTL changes the behavior of threading on Linux (actually makes it more POSIX compliant). These subtle changes in behavior tend to cause problems with complex software that is tightly tied to the underlying thread model. Certainly the existing Linux JVM's have had a LOT of tweaking done to them in order to deal with "differences" in Linux's thread model. This is also a problem for the WINE project (as another example). So, the simple thing to do is disable NPTL and use the old, less scalable thread model (basically you just set an environment variable and magically glibc uses LinuxThreads-style pthreads). It's my understanding that the Sun JVM does this, as does the WINE project. I am not certain about the IBM VM, but since they have not released a new VM since NPTL was released on a mainstream Linux platform (RH9), I suspect this is not the case. Someone who knows more, please let me know. I suspect that prior to NPTL being usable, changes will have to be made both the VM and the standard libraries. Perhaps with luck Sun/IBM/etc. can just use code from other POSIX platforms. I don't know. That's not clarification. It's spreading wrong information. OK, I'm not a wine expert nor am I allowed to read IBM code. But I can speak for Sun JVM. No, there is no magic flag or whatever within JVM to disable NPTL. If you are running java on RH9 (or 2.5.xx kernel) with NPTL, you are indeed using the new pthread library. Still not convinced? Try creating more than 1024 threads, that's something you couldn't do without NPTL. There has been a lot of work done in the past to make this happen. Drop me an email if you'd like to hear more about the boring story of threading support within JVM ;-) thanks, -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Max number of threads with NPTL
Nathan Bryant wrote: Daniel Malmkvist wrote: To my supprise i could not have more then ~3500 threads at the same time. I got a OutOfMemoryException, but there was plenty of system memory left (the JVM only ha about 10% of system physical memory). Address space might be a limiting factor in a 32-bit machine. Assuming a 3gig/1gig VM split, you have less than a megabyte per thread stack at 3500 threads, even assuming there is no other memory overhead, and there is a lot of other overhead... Did you try using the Thread constructor that specifies a stack size? Try specifying a single page - 4K. You might also need to increase the maximum size of the Java heap. (Or decrease it to make room for more stack?) I have found that it can't grow beyond 1.5gig on x86. If you are allocating the default stack size which is probably fairly large, Default stack size is 512k. You need 3500 * 512k = 1750M address space for 3500 threads. Try -Xss96k. Also check your limit on max #processes (ulimit -u), you can't create more threads than that limit either. regards, -hui the system won't appear to be using the memory because the stack pages won't have corresponding physical pages allocated by the VM until they are used - the stacks grow down. But they are still allocated virtual address space within the process. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Max number of threads with NPTL
Vincent Touquet wrote: On Wed, Feb 04, 2004 at 09:56:57AM -0800, Hui Huang wrote: Default stack size is 512k. You need 3500 * 512k = 1750M address space for 3500 threads. Try -Xss96k. Also check your limit on max #processes (ulimit -u), you can't create more threads than that limit either. Is there a common place where these options (eg. -Xss...) are documented? See: http://java.sun.com/docs/hotspot Also, you can get a list of common options by just running "java" or "java -X". regards, v -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: stack size to small?
JVM fataled because it's an irrecoverable error (i.e. not as simple as StackOverflowError). Prior to 1.5, Sun's JDK needs to allocate alternate signal stack to handle stack overflows. For compatibility reasons, the alt stack is actually allocated within the normal thread stack. If a thread (either a pure Java thread or a native thread attached to VM) does not have enough stack space for the alt stack, JVM will have to abort (JVM can't continue because signal handlers have already been set up to use alternate signal stack; each thread must have its own alt stack, if any thread is missing alt stack, you'll end up having two threads sharing the stack space, which will lead to crashes that are much harder to diagnose). Alt signal stacks have been removed in 1.5. I'd recommend you to try JDK 1.5-beta, which is available at java.sun.com. You might also want to check your code (both Java and native) to see if you are creating threads with small stack. Before 1.5, the minimum stack size allowed is 96k. regards, -hui Joseph Shraibman wrote: That's what StackOverflowError is for. It shouldn't crash the jvm Dan Kegel wrote: Joseph Shraibman wrote: I had a jvm running for a few hours when it suddenly quit with: Fatal: Stack size too small. Use 'java -Xss' to increase default stack size. WTF? Maybe you allocated something huge on the stack, or had too many levels of nested calls... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: stack size to small?
The alt stack is allocated during thread creation. OutOfMemoryError might be a better choice than outright fatal. But keep in mind OutOfMemoryError is already very generic, it's not so easy to figure out what actually caused the OOM. Like I said, a better fix is to not use alt stack at all. It is implemented in 1.5. thanks, -hui Joseph Shraibman wrote: This alt stack is allocated when? I'm confused. If at thread creation, then the thread.start() should fail with an OutOfMemError. If it is allocated when a stack overflow occurs, well of course there won't be space to allocate the alt stack because we just had a stack overflow Hui Huang wrote: JVM fataled because it's an irrecoverable error (i.e. not as simple as StackOverflowError). Prior to 1.5, Sun's JDK needs to allocate alternate signal stack to handle stack overflows. For compatibility reasons, the alt stack is actually allocated within the normal thread stack. If a thread (either a pure Java thread or a native thread attached to VM) does not have enough stack space for the alt stack, JVM will have to abort (JVM can't continue because signal handlers have already been set up to use alternate signal stack; each thread must have its own alt stack, if any thread is missing alt stack, you'll end up having two threads sharing the stack space, which will lead to crashes that are much harder to diagnose). Alt signal stacks have been removed in 1.5. I'd recommend you to try JDK 1.5-beta, which is available at java.sun.com. You might also want to check your code (both Java and native) to see if you are creating threads with small stack. Before 1.5, the minimum stack size allowed is 96k. regards, -hui Joseph Shraibman wrote: That's what StackOverflowError is for. It shouldn't crash the jvm Dan Kegel wrote: Joseph Shraibman wrote: I had a jvm running for a few hours when it suddenly quit with: Fatal: Stack size too small. Use 'java -Xss' to increase default stack size. WTF? Maybe you allocated something huge on the stack, or had too many levels of nested calls... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 1.3, kernel 2.6, signals
Hi Nicole,
I tested your code. It works fine on my machine with 2.6.4. I
tested Sun JDK 1.3.1fcs, 1.3.1_10, 1.3.1_11, 1.4.2fcs, 1.4.2_03
and 1.5beta. SignalTest is able to catch HUP, TERM, INT.
That said, I'd like to point out that the Java level signal API
is private interface. Its sole purpose is to implement the shutdown
mechanism (see Runtime.addShutdownHook). The interface may change
or get dropped completely without notice in future JDK. So use at
your own risk. (If you really want to catch signals, it's better
to write JNI code; signals have well-defined behavior at C level,
but not at Java level).
regards,
-hui
nicole wrote:
Ah, the IBM JDK was holding the signals for the JVM, that explains why
that didn't work (had to use -Xrs).
Works with 2.6:
IBM 1.3.1-6 (with -Xrs)
Sun 1.4.2_03 (no -Xrs)
Does Not Work with 2.6:
Blackdown 1.3.1
Sun 1.3.1_10
Sun 1.3.1_11
Untested:
Blackdown 1.4.x
IBM 1.4.x
Everything tested works fine on a 2.4 kernel.
Attached is the test code that I am using to test the signals.
Feedback welcome... otherwise I am most likely going to test and switch to
the IBM 1.3.1-6 JRE.
Thanks!
-nicole
At 16:52 on Mar 17, nicole shook the earth with:
The IBM JRE did not appear to catch the signals at all, they get passed
right through and kill the application.
Once I have something that tests the signals exclusively, hopefully I can
test all three of the JVMs and see what happens.
At 12:13 on Mar 16, Tony Reix shook the earth with:
Hi Nicole,
{ ...
{ I will be constructing a basic application that just does the signal
{ handling similar to my application so I can use it to test.
Seems your problem is not easy to understand ...
Let us know when you have built such a basic application. At that
time we'll try to reproduce it there, probably with the Sun or IBM JVMs.
Did you try with IBM JVM ?
Thanks for helping stabilizing NPTL.
package test;
import sun.misc.Signal;
import sun.misc.SignalHandler;
import java.io.*;
public class SignalTest implements SignalHandler
{
public SignalTest()
{
}
public static void main(String[] args)
{
SignalTest st = new SignalTest();
st.run();
}
public void run()
{
System.out.println("Initializing Signals...");
initSignals();
System.out.println("Signals Initialized.");
System.out.println("I'm going to sit here now while you try to kill me"
+ " (type exit to force quit)");
BufferedReader _input = new BufferedReader(new InputStreamReader(System.in));
String s = "foo";
while(!(s.equals("exit")))
{
try
{
s = _input.readLine();
s = s.trim();
}
catch(java.io.IOException e)
{
System.out.println("oops, I didn't expect that: " + e.toString());
}
}
System.out.println("Exiting on user request.");
System.exit(0);
}
protected void initSignals()
{
try
{
System.out.println("Initializing sig INT");
Signal.handle(new Signal("INT"), this);
}
catch(IllegalArgumentException e)
{
// failed
System.out.println("Signals Caught:" + e.toString());
}
try
{
System.out.println("Initializing sig HUP");
Signal.handle(new Signal("HUP"), this);
}
catch(IllegalArgumentException e)
{
// failed
System.out.println("Signals Caught:" + e.toString());
}
try
{
System.out.println("Initializing sig TERM");
Signal.handle(new Signal("TERM"), this);
}
catch(IllegalArgumentException e)
{
// failed
System.out.println("Signals Caught: " + e.toString());
}
try
{
System.out.println("Initializing sig USR1");
Signal.handle(new Signal("USR1"), this);
}
catch(IllegalArgumentException e)
{
// failed
System.out.println("Signals Caught: " + e.toString());
}
}
public void handle(Signal sig)
{
System.out.println("Caught " + sig.toString() + " ("+sig.getNumber()+")");
if(sig.toString().equals("SIGTERM"))
{
System.out.println("Caught sig TERM, exiting");
System.exit(-1);
}
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: segfault on x86_64 (Fedora Core 2) 2.6.x
The segfault messages look benign - they are the implicit NULL checks within JVM. Did you see a hang or a crash (i.e. tomcat process is gone, segfaults in kernel log don't count, they are handled by JVM)? Is this on HT Xeon? I've heard 2.6.5 in FC2 is not stable (frequent hang) but 2.6.6 is Ok, looks like your case is different. I haven't got a chance to load FC2 on my machine yet. regards, -hui Marc Heckmann wrote: Hi, I am using j2sdk-1.4.2 on Fedora Core 2 x86_64. when starting tomcat v4.1.30 (haven't tried any other version), I get segfaults and my webapps do not run properly at all. This happens with either the 32 bit or native 64 bit versions of the SDK. I have tried on 2 separate machines with the same results. Here are some of the messages I get: java[4508]: segfault at 0008 rip 002a98544a78 rsp 007fbfffc1d0 error 4 java[4520]: segfault at 0008 rip 002a9845f3c2 rsp 4148bf20 error 4 The same thing happens with Sun's SDK. Kernel version 2.6.7-rc2-bk6 as well as 2.6.6. Kernel 2.4.27-rc5 does not show this behaviour. Anyone seen this before? Thanks in advance. -m -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does anyone have any idea when bug 4813310 will be fixed?
Joseph Shraibman wrote: Does the sun version make the call? Does blackdown? Just curious, it doesn't appear as if it will matter any time soon :( Sun JVM does call pthread_setschedparam(), but of course this wouldn't make any difference ... Thread priority is one of the scheduling issues that have been raised many many times (the other one is java.lang.Thread.yield()), but really there is no good solution because of missing functionality inside Linux kernel. You might be interested in this article about the situation on Solaris: http://java.sun.com/j2se/1.5.0/docs/guide/vm/thread-priorities.html regards, -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help on JVM hang
Is this on Redhat 9? If so, try this:
+ find out java process id
+ use gdb to attach to the process (gdb - )
+ quit gdb
wait a few seconds, does the process start to run again? If yes,
it's a known RH-9 issue (a notification from pthread_cond_broadcast
is lost in NPTL). Update to AS-3 or set LD_ASSUME_KENREL should
fix it.
regards,
-hui
Joseph Shraibman wrote:
Just got another hang:
"RMI TCP Connection(5752)-199.107.233.207" daemon prio=1 tid=0x08243e08
nid=0x2420 waiting on condition [4e601000..4e602854]
at java.util.zip.Inflater.inflate(Inflater.java:219)
- waiting to lock <0x46292948> (a java.util.zip.Inflater)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:128)
at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:408)
at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:450)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:182)
- locked <0x46317cd8> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
- locked <0x46317cd8> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at
org.apache.xerces.util.ObjectFactory.findJarServiceProvider(Unknown Source)
at org.apache.xerces.util.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.util.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.DOMParser.(Unknown Source)
at org.apache.xerces.parsers.DOMParser.(Unknown Source)
Joseph Shraibman wrote:
Kinda looks like what happened to me. A lot of threads "waiting on
condition" for no reason at all. For example:
"Thread-206" prio=1 tid=0x087b7d18 nid=0x7b88 waiting on condition
[6e01e000..6e01f854]
at java.util.Stack.pop(Stack.java:59)
at org.apache.log4j.NDC.pop(NDC.java:274)
... and Stack.java looks like:
public synchronized Object pop() {
Object obj;
int len = size(); //<= line 59
obj = peek();
removeElementAt(len - 1);
return obj;
}
Veda N Ponnusamy wrote:
Please find attached the thread dump of the JVM. I didn't try running
this app on 1.5 jvm
Reg
Veda
-Original Message-
From: Joseph Shraibman [mailto:[EMAIL PROTECTED]
Sent: Friday, June 11, 2004 1:26 PM
To: Calvin Austin
Cc: Veda N Ponnusamy; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Help on JVM hang
Calvin Austin wrote:
Does it ever resume. 1.5beta2 has more diagnostics in it and you may
be able to even attached with jdb (hey tim :*)
Without seeing the other threads its difficult to see what is
happening, however there was a bug fix in 1.5 to stop the cache
growing out of control. A quick test with 1.5 would help a great deal.
I was never able to reproduce the hang on a test machine, it only
happened in production under load. My boss would kill me if I ran a
beta jvm in production.
I also haven't seen the bug for a couple of weeks since I limited the
work done by that jvm in order to avoid the bug. And I'm not going
to risk freezing our system in order to hit the bug again.
If I did attach to the jvm with jdb, what good would it do? What
would I see that the SIGQUIT thread dump wouldn't show?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help on JVM hang
Veda N Ponnusamy wrote:
Hi,
We set the LD_ASSUME_KERNEL=2.2.5 and the hang goes away. But the application
is running at 60% speed !!
Interesting. You could try LD_ASSUME_KERNEL=2.4.1 (the floating
stack version of LinuxThreads), it's generally faster than 2.2.5.
Do you know any patches anywhere for this problem ???
Unfortunately, no, Redhat did not release the patch. RH9 is the
only platform we've seen this problem. We didn't stress test
Fedora Core, but AS-3 works Ok.
thanks,
-hui
P.S. Next time when you see the hang, please try the gdb trick
to id the bug. If the process still hangs after attach-detach
with gdb, it's something else.
Reg
Veda
-Original Message-
From: Hui Huang [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 24, 2004 10:39 AM
To: Joseph Shraibman
Cc: [EMAIL PROTECTED]; Veda N Ponnusamy; [EMAIL PROTECTED]
Subject: Re: Help on JVM hang
Is this on Redhat 9? If so, try this:
+ find out java process id
+ use gdb to attach to the process (gdb - )
+ quit gdb
wait a few seconds, does the process start to run again? If yes,
it's a known RH-9 issue (a notification from pthread_cond_broadcast
is lost in NPTL). Update to AS-3 or set LD_ASSUME_KENREL should
fix it.
regards,
-hui
Joseph Shraibman wrote:
Just got another hang:
"RMI TCP Connection(5752)-199.107.233.207" daemon prio=1 tid=0x08243e08
nid=0x2420 waiting on condition [4e601000..4e602854]
at java.util.zip.Inflater.inflate(Inflater.java:219)
- waiting to lock <0x46292948> (a java.util.zip.Inflater)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:128)
at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:408)
at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:450)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:182)
- locked <0x46317cd8> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
- locked <0x46317cd8> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at
org.apache.xerces.util.ObjectFactory.findJarServiceProvider(Unknown Source)
at org.apache.xerces.util.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.util.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.DOMParser.(Unknown Source)
at org.apache.xerces.parsers.DOMParser.(Unknown Source)
Joseph Shraibman wrote:
Kinda looks like what happened to me. A lot of threads "waiting on
condition" for no reason at all. For example:
"Thread-206" prio=1 tid=0x087b7d18 nid=0x7b88 waiting on condition
[6e01e000..6e01f854]
at java.util.Stack.pop(Stack.java:59)
at org.apache.log4j.NDC.pop(NDC.java:274)
... and Stack.java looks like:
public synchronized Object pop() {
Object obj;
int len = size(); //<= line 59
obj = peek();
removeElementAt(len - 1);
return obj;
}
Veda N Ponnusamy wrote:
Please find attached the thread dump of the JVM. I didn't try running
this app on 1.5 jvm
Reg
Veda
-Original Message-
From: Joseph Shraibman [mailto:[EMAIL PROTECTED]
Sent: Friday, June 11, 2004 1:26 PM
To: Calvin Austin
Cc: Veda N Ponnusamy; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Help on JVM hang
Calvin Austin wrote:
Does it ever resume. 1.5beta2 has more diagnostics in it and you may
be able to even attached with jdb (hey tim :*)
Without seeing the other threads its difficult to see what is
happening, however there was a bug fix in 1.5 to stop the cache
growing out of control. A quick test with 1.5 would help a great deal.
I was never able to reproduce the hang on a test machine, it only
happened in production under load. My boss would kill me if I ran a
beta jvm in production.
I also haven't seen the bug for a couple of weeks since I limited the
work done by that jvm in order to avoid the bug. And I'm not going
to risk freezing our system in order to hit the bug again.
If I did attach to the jvm with jdb, what good would it do? What
would I see that the SIGQUIT thread dump wouldn't show?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help on JVM hang
Joseph Shraibman wrote:
Hui Huang wrote:
Veda N Ponnusamy wrote:
Hi,
We set the LD_ASSUME_KERNEL=2.2.5 and the hang goes away. But the
application
is running at 60% speed !!
Interesting. You could try LD_ASSUME_KERNEL=2.4.1 (the floating
stack version of LinuxThreads), it's generally faster than 2.2.5.
Do you know any patches anywhere for this problem ???
Unfortunately, no, Redhat did not release the patch. RH9 is the
only platform we've seen this problem. We didn't stress test
Fedora Core, but AS-3 works Ok.
So you do have code that can reproduce this problem? It would help a
lot if I could get it.
No special test case. We run a tomcat server and have clients to
talk to it repetitively. I tried to create a small testcase when I
reported the bug, but it wasn't easy.
thanks,
-hui
P.S. Next time when you see the hang, please try the gdb trick
to id the bug. If the process still hangs after attach-detach
with gdb, it's something else.
Would strace -p work as well?
From: http://bugs.mysql.com/bug.php?id=868
One interesting side note is that if you strace the right process, the
system
will recover. However, we have still had database corruption when we
did this.
It looks like the same issue. IIRC, the problem happened when one
thread sleeps on pthread_cond_wait, and another thread in
pthread_cond_{signal,broadcast} to wake up the first thread,
sometimes kernel failed to change the first thread back to running.
Both gdb and strace use the ptrace interface, when PTRACE_DETACH
happens, kernel will wake up the process/thread no matter what its
previous state is. When gdb is detached from a process, it will
PTRACE_DETACH every thread (including the one waiting in cond_wait),
that's why the gdb trick can break the hang. Another way to break
the hang is to send a signal to the "right" process/thread.
regards,
-hui
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help on JVM hang
Joseph Shraibman wrote: Hui Huang wrote: Is this on Redhat 9? If so, try this: + find out java process id + use gdb to attach to the process (gdb - ) + quit gdb wait a few seconds, does the process start to run again? If yes, it's a known RH-9 issue (a notification from pthread_cond_broadcast is lost in NPTL). Update to AS-3 or set LD_ASSUME_KENREL should fix it. regards, -hui What about this? http://gcc.gnu.org/ml/java/2004-05/msg00064.html Do you know what he's talking about? Not familiar w/ ResourceBundle implementation. But it looks like a performance trick to avoid frequent lookup for class loader, nothing to do with the hang. -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Crashes/Hangs on Mandrake 10.0
That sounds like an OS issue. A user application such as Java does not have the power to take down the whole system. BTW, if you believe the issue is in Sun JDK, you should definitely file a bug with Sun. Sorry to hear your past experience isn't good, sometimes a bug is given a low priority due to its limited impact, or assigned to the wrong group by mistake, so it may remain under the radar for a while before being looked at... regards, -hui Richard -Gilligan- Uschold wrote: I'm not sure if this is the correct place to report this, but I couldn't find a bug report link. I could submit to Sun, but I've done that several times in the past, and they've never managed to fix anything. They take nearly a year to respond, and then can't reproduce the problem, and dismiss it as nor reproducible. For another bug I reported, they said it was the same as an already reported bug, but haven't fixed that one yet either. A program I wrote, scoreRegatta crashes/hangs on Mandrake 10.0, but ran fine on Mandrake 8.0. Even Ctrl-Alt-F2 is ignored! The only way to recover is to hit the reboot button on the computer. I was running Sun's v 1.4.2 on both drake 8.0 and drake 10.0: 46 pluto ~> java -version java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) I tried kaffee and gij, hoping these VM's might not have this problem, but neither will run even the most rudimentary gui application. I tried blackdown java, which fails the same as Sun's java. 47 pluto ~> bjava -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) Client VM (build Blackdown-1.4.2-rc1, mixed mode) The crash happens during the initialization phase of scoreRegatta. The progress bar has been as various positions between 50% and 80% during the hang. I switched from Mandrake 8.0 to Mandrake 10.0 a few months ago, because Mandrake 8.0 would always hand during shutdown, failing to kill some process, and forcing ckdsk at every reboot. Another related reason for switching, is that debugging scoreRegatta in NetBeans would often hang NetBeans. In particular, one java process would be in the "DiskSleep" state, and Netbeans would hang. I would kill the java processes and start NetBeans again. Unfortunately, theDiskSleep process can not be killed! Not even as root, not with -9 option, and worst of all, shutting down linux would not kill it either! Which would also force ckdsk on reboot. The program: installation package, including jar file: (README describes installation) http://dbh3.us/cgi-bin/getZip/scoreRegatta.zip java Source files: http://dbh3.us/cgi-bin/getZip/RegattaSrc.zip -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Swing doesn't work on jdk117
I've just downloaded jdk117v1a. Then I tested it with the SwingSet example comes with swing1.0.3. When I started it, it generated a segment fault. Did I miss something? Alex Hui [EMAIL PROTECTED]
help me
hi! can you help me? i have the following error whenever i run every programs included in linux jdk 1.1.6. what happened? first of all, i got "Segmentation fault" with libc library in jdk. so i removed it coz i have already installed the same version of libc. then i can run some programs. but they didn't work with this error. please help me. i couldn't subscribe [EMAIL PROTECTED] coz mail returned to me. mail server couldn't find it's id. help me. and sorry for my lame english Regards, Huidae Cho [EMAIL PROTECTED] === SIGSEGV 11* segmentation violation Full thread dump: Monitor Cache Dump: Registered Monitor Dump: Monitor IO lock: Child death monitor: Event monitor: I/O monitor: Alarm monitor: Monitor registry: Thread Alarm Q: ===
