JDK-8015837 : Nashorn crashes with tiered on x86 when running v8 benchmark
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2013-06-03
  • Updated: 2023-07-21
  • Resolved: 2023-07-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8-poolResolved
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
I'm seeing numerous crashes on x86 while running nashorn with the v8 benchmarks. This is on a dual-core machine, and the problem seems to go away when -XX:-BackgroundCompilation is added. Command line is:

/java/re/jdk/8/promoted/latest/binaries/linux-i586/bin/java -XX:+TieredCompilation -XX:+PrintCodeCache -jar /java/re/jdk/8/promoted/latest/binaries/linux-i586/jre/lib/ext/nashorn.jar run.js

Here are 5 of the crashes. hserr files are attached:

#  SIGSEGV (0xb) at pc=0xab8d8a52, pid=15097, tid=3078216560
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b92) (build 1.8.0-ea-b92)
# Java VM: Java HotSpot(TM) Server VM (25.0-b34 mixed mode linux-x86 )
# Problematic frame:
# J  jdk.nashorn.internal.scripts.Script$splay._L293(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

#  SIGSEGV (0xb) at pc=0xa9f6b539, pid=14645, tid=3077606256
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b92) (build 1.8.0-ea-b92)
# Java VM: Java HotSpot(TM) Server VM (25.0-b34 mixed mode linux-x86 )
# Problematic frame:
# J  jdk.nashorn.internal.scripts.Script$raytrace._L426(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

#  SIGSEGV (0xb) at pc=0xa8b81c67, pid=14494, tid=3078482800
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b92) (build 1.8.0-ea-b92)
# Java VM: Java HotSpot(TM) Server VM (25.0-b34 mixed mode linux-x86 )
# Problematic frame:
# J  jdk.nashorn.internal.scripts.Script$richards._L324(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object;

#
#  SIGSEGV (0xb) at pc=0xa933ec14, pid=14583, tid=3078015856
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b92) (build 1.8.0-ea-b92)
# Java VM: Java HotSpot(TM) Server VM (25.0-b34 mixed mode linux-x86 )
# Problematic frame:
# J  jdk.nashorn.internal.scripts.Script$deltablue._L691(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Z

#  SIGSEGV (0xb) at pc=0xaa63981a, pid=14597, tid=3077729136
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b92) (build 1.8.0-ea-b92)
# Java VM: Java HotSpot(TM) Server VM (25.0-b34 mixed mode linux-x86 )
# Problematic frame:
# J  jdk.nashorn.internal.scripts.Script$earley_boyer$6._L3604(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
#

Comments
Bug report actually contains multiple issues, the attached logs refer to JDK-8014959 and JDK-8023956
16-10-2013

Some of the crashes I was seeing may be attributable to JDK-8024008.
09-09-2013

File https://bugzilla.redhat.com/show_bug.cgi?id=996149 for the SI_KERNEL issue. Only real work-around would be to map PROT_EXEC a high VA and exec some code in it.
14-08-2013

Although I don't doubt there are still versions of the patch with a configurable option, all the "arch/x86/kernel/traps.c" I reviewed for the distros listed had the lazy code segment handling hard coded on, the only condition being a compile define (X86_32). I.e. RHEL 5 & 6, Ubuntu 10.04, 11.04, 12.04 have no work-around, no way to disable.
12-08-2013

Just to clarify, does the following indicate exec shield is running on my device: $> grep check_lazy_exec_limit /boot/System.map-`uname -r` c0104150 t check_lazy_exec_limit I've been looking at ways to disable exec shield. I found two, but both fail in a way that seems to indicate that I don't have exec shield installed. $> sudo sysctl -w kernel.exec-shield=0 error: "kernel.exec-shield" is an unknown key $> echo 0 | sudo tee /proc/sys/kernel/exec-shield tee: /proc/sys/kernel/exec-shield: No such file or directory 0
12-08-2013

SI_KERNEL problem: I can now confirm check_lazy_exec_limit() is interrupted by smp_invalidate_interrupt() (IPI signal) which updates the current CS (load_user_cs_desc()). If this occurs after check_lazy_exec_limit() sets the new limit but before it loads and compares the current CS descriptor, it will erroneously signal us: ... set_user_cs(&current->mm->context.user_cs, limit); //**** IPI from here to comparison (__compare_user_cs_desc) will load_user_cs_desc() ****// desc1 = &current->mm->context.user_cs; desc2 = get_cpu_gdt_table(cpu) + GDT_ENTRY_DEFAULT_USER_CS; if (__compare_user_cs_desc(desc1, desc2)) { //*** smp_invalidate_interrupt() already updated ... The code then assumes the general protection fault wasn't because of the exec shield lazy CS update (but it was). Results in the general protection trap handler forcing a SIGSEGV on us (should have just returned since CS had been fixed up). This Linux bug affects only 32bit Intel, and only distributions whom have added the "Exec Shield" patch (local test, use "grep check_lazy_exec_limit /boot/System.map-$(uname -r)" find the function), including: * Ubuntu 10.04 LTS, 11.04, 12.04 * RHEL5 & RHEL6 (with latest updates) * OL/OEL5 & 6 WHEN NOT USING UEK. This bug requires a race with lazy code segment updates and IPI signalling (for MM sync over SMP). Since the JVM generates dynamic code (changing CS) it is more susceptible than most applications.
12-08-2013

I've believe Coleen's comment regarding SIGSEGV:SI_KERNEL crashes is correct, it is an OS bug. I managed to reproduce with i686 Ubuntu 10.04 desktop within VirtualBox, then proceeded to instrument the kernel: attached "instrument.diff" and resulting log (tail) "instrument.log". Source, use: apt-get source linux-image-$(uname -r). I noticed that this particular kernel, on i686 specifically (X86_32), Debian has added the "Exec Shield" patch (http://en.wikipedia.org/wiki/Exec_Shield). Uses CS segment limit in an attempt to increase security by restricting running code within "exec_limit". See "arch/x86/kernel/traps.c:check_lazy_exec_limit()" (for patch details: http://www.linux-archive.org/ubuntu-kernel-team/281457-sauce-x86-32-implement-cs-limit-nx-emulation.html). On #GP fault (arch/x86/kernel/traps.c:do_general_protection()) the current task vma list is iterated for the largest executable page and then lazy updates the CS limit. Most applications have fixed native code which doesn't exercise this lazy exec_limit updating much. The JVM is of course different, we generate code on one CPU and run on another, along with a number of mmap related ops (especially this nashorn reproducer). Aug 9 13:14:00 dsimmsv05 kernel: [ 494.553941] ### (1) java check_lazy_exec_limit: UPDATED CS old limit = 0xa9d48000 new limit = 0xa9d48000 Aug 9 13:14:01 dsimmsv05 kernel: [ 494.918085] ### (3) java check_lazy_exec_limit: UPDATED CS old limit = 0xa9d58000 new limit = 0xa9d58000 Aug 9 13:14:01 dsimmsv05 kernel: [ 495.072140] ### (3) java check_lazy_exec_limit: NOT UPDATED CS old limit=0xa9d68000 new limit=0xa9d68000 (ip=0xa9d5fff2 sp=0xb77491c0) Aug 9 13:14:01 dsimmsv05 kernel: [ 495.072166] Aug 9 13:14:01 dsimmsv05 kernel: [ 495.072168] ### CS current task 9d67:cafb00 vs CPU 9d67:cafb00 vs orig 9d5f:cafb00 ### <<<==== CS orig DOES NOT MATCH Aug 9 13:14:01 dsimmsv05 kernel: [ 495.072170] code at a9d5fff2: eb 1e ba 50 51 9f 8b b9 f0 43 79 8a ff 74 24 2c Notes: * #GP fault with valid totally valid IP and code there-in (EIP=0xa9d5fff2) ** "0xa9d5fff2: jmp 0xa9d60012" * the check_lazy_exec_limit() comparison of the exec_limit and current CS match, and EIP lies within (which is why it drops into force_sig) * yet the orig code segment descriptor recorded upon entry to check_lazy_exec_limit() differs: orig 9d5f:cafb00 limit = 0xa9d5f0000 ** EIP clearly lies outside the original limit causing the general protection fault to begin with. * The actual exec_limit (0xa9d68000) was never updated. I don't yet fully understand how this occurs, although... Probable cause notes: * One suspect is check_lazy_exec_limit() iterating over vma, it doesn't take the required mmap_sem. The page_table_lock won't protect against mmap.c ops on SMP. * Just noticed do_general_protection() enables interrupts... ** IPI signalling will trigger smp_invalidate_interrupt() which can mess with CS If I am correct the SI_KERNEL crashes only occur on older kernels containing the exec shield patch (this has never seen main-line Linux) on i686 only. Newer Ubuntu Linux 3.x based kernels don't use the patch. As I understand bug reports related to SI_KERNEL crashes so far, meet that criteria. Further speculation welcome.
09-08-2013

Instrumented kernel and resulting log
09-08-2013

Linux carrs 2.6.32-37-generic #81-Ubuntu SMP Fri Dec 2 20:35:14 UTC 2011 i686 GNU/Linux Ubuntu 10.04.4 LTS I think it's still an OS bug. From my strace output, it appears that we're about to run out of process space because we're mmapping arenas for what look like large compilations (on linux malloc is mmap) and then we unmap something, then crashes. [pid 13513] mmap2(0xa9f19000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xa9f19000 [pid 13513] mmap2(0xa8086000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xa8086000 [pid 13512] munmap(0x80cfb000, 1069056 <unfinished ...> [pid 13512] <... munmap resumed> ) = 0 [pid 13502] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 13502] write(1, "# To suppress the following erro"..., 63 <unfinished ...> I don't know what the mmap 1069056 is for yet.
31-07-2013

Chris we have no data on that AFAIK. I think it more likely that this is actually a code bug.
31-07-2013

What needs to be done to fix a linux distro so it no longer has this SI_KERNEL problem? Is it a kernel updgrade that is needed? How can you tell from uname output if the system is problematic.
31-07-2013

Vladimir, I think that is the same as Coleen found previously - inspecting around the apparent crash site did not in fact show anything incorrect.
25-07-2013

It SEGV on branch instruction (hs_err_pid15097.log): ab8d8a4c 81 fd c8 1d 1f 78 cmp $0x781f1dc8,%ebp --------------- ab8d8a52 0f 85 25 06 00 00 jne 0xab8d907d ab8d8a58 81 ff 08 ac 3d 71 cmp $0x713dac08,%edi It is inside codecache, I don't see anything wrong here: CodeCache: size=245760Kb used=55046Kb max_used=55082Kb free=190713Kb bounds [0xa82f9000, 0xab8f1000, 0xb72f9000] total_blobs=13484 nmethods=13240 adapters=157 compilation: enabled a82f9000-ab8f1000 rwxp 00000000 00:00 0 ab8f1000-b72f9000 ---p 00000000 00:00 0 I looked on an other hs_err_pid25436.log and it is the same: --------------- aa030b09 0f 85 52 39 00 00 jne 0xaa034461 CodeCache: size=245760Kb used=30541Kb max_used=30583Kb free=215218Kb bounds [0xa8281000, 0xaa091000, 0xb7281000]
25-07-2013

I think any crash will do as all the logs show these are in fact SI_KERNEL cases.
25-07-2013

The crash happens on nearly half the runs of nashorn with the v8 benchmark. However, getting it to NOT report "An irrecoverable SI_KERNEL SIGSEGV has occurred..." is rare. I only saw it once out of around 15 crashes. This is a 32-bit system. I'll try with ShowMessageBoxOnError. Do you want any crash, or only one without "An irrecoverable SI_KERNEL SIGSEGV has occurred..."?
25-07-2013

Does whoever figure this out get $64 mil? n-2 Comment: I put the if (info != NULL && uc != NULL && thread != NULL) { for the java thread, but I guess this signal can affect other threads. Is this reproduceable on a specific system now? Can someone run this with ShowMessageBoxOnError and dump every register and instruction set in every frame? Is there any indication at all in the crash that we stomped outside the 64 bit process limit?
25-07-2013

That is the $64M question. Previously it was thought this was bogus but as I posted above now it seems it could be real crash if we have memory stomped outside the 32-bit process limit.
25-07-2013

If I get the "An irrecoverable SI_KERNEL SIGSEGV has occurred..." message, does that indicate a real crash, but an inability to accurately report it, or does it indicate a bogus crash due to some sort of linux kernel issue?
25-07-2013

It looks like the difference is compiler-thread versus Java thread. In the later case we don't enter the if block: if (info != NULL && uc != NULL && thread != NULL) { and so we don't hit the new SI_KERNEL check. I'm wondering if that should have been outside the if block ??
25-07-2013

You're right! I missed that because the error was reported differently. All the other hs_err files contain: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (os_linux_x86.cpp:298), pid=24784, tid=3078216560 # fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution. 25436 contains: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xaa030b09, pid=25436, tid=3077942128 # # JRE version: Java(TM) SE Runtime Environment (8.0-b93) (build 1.8.0-ea-b93) # Java VM: Java HotSpot(TM) Server VM (25.0-b34 mixed mode linux-x86 ) # Problematic frame: # J jdk.nashorn.internal.scripts.Script$earley_boyer$7._L3813$_L3965$_L4254$_L4258$_L4272(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; And it also contains: siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x00000000 Any idea why it has useful stack info and did not report "An irrecoverable SI_KERNEL SIGSEGV has occurred..."
25-07-2013

Chris: hs_err_pid25436.log contains si_code=128 which is the SI_KERNEL value.
25-07-2013

If I run the latest fastdebug (b99) without -XX:MaxNodeLimit=300000, I still see the assert, so this problem has not been fixed yet: # Internal Error (/HUDSON/workspace/2-build-linux-i586/jdk8/5145/hotspot/src/share/vm/opto/node.cpp:71), pid=6578, tid=1856498544 # assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit
24-07-2013

I just noticed one of my crashes yesterday was not an SI_KERNAL. See attached hs_err_pid25436.log.
24-07-2013

Or perhaps not. I found this interesting discussion: http://unix.stackexchange.com/questions/71240/sigaction7-semantics-of-siginfo-ts-si-code-member in particular: "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL"
24-07-2013

Chris, if you are getting si_code=128 (SI_KERNEL) then you aren't losing meaningful crash information because the crashes are quite likely bogus. 8004124 is unfortunately not very clear on the issue. There is a little more info on the review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-June/007825.html but the gist is that this indicates a kernel problem.
24-07-2013

I'm using Ubuntu 10.04 and kernel 2.6.32-48. I'd update to something newer if the LDAP instructions worked for it. I don't understand the issues described in JDK-8004124, but I know that for me the fix has resulted in losing meaningful crash information. I'll probably end up removing the new code for my local builds.
23-07-2013

Chris, the new crash would seem to indicate you have a "bad" linux distro that needs to be updated. Looking at the other crash reports I see si_code=128 which is the SI_KERNEL code.
23-07-2013

Can you try on Solaris?
22-07-2013

With the latest JDK 8 release, I still see frequent crashes (about half the runs) when I don't use -XX:MaxNodeLimit=300000. With -XX:MaxNodeLimit=300000, it crashes much less frequently, but still crashes. In both cases, the crashes always show up as: # Internal Error (os_linux_x86.cpp:298), pid=24784, tid=3078216560 # fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution. This is different than I used to see. This message seems to come from code introduced recently by the fix for JDK-8004124.
22-07-2013

I was still seeing it about 3 weeks ago. I've been on vacation most of the time since then so I haven't tried recently. I'll be updating my repo later this week and will start doing some testing again. Will let you know how it goes.
17-07-2013

Chris Plummer, Are you still seeing this issue?
17-07-2013

Going back that far is dangerous. The version could have other bugs which have been fixed already.
12-06-2013

That was exactly what I tried to figure out. However, I could not find a version that worked.
12-06-2013

Why do you need to run old versions, unless you are trying to see if there is a version where the bug got introduced. It reproduces with b92 and later. I'm not sure about anything before that.
12-06-2013

Hi, I tried to go back a couple of versions. In b88 (25.0-b30-fastdebug) we hit 8013036, which crashes Hotspot pretty frequently. I am not sure how much further (if at all?) going back makes sense...
12-06-2013

Just let me know when your are on it. I'm doing a lot of benchmarking on it lately. My use is generally between 8am and 11pm PST. I'm not using it that whole time, but need to make sure you aren't using when I run more benchmarks.
11-06-2013

Sure, that makes sense. In the future you can mention your machine name in one of the comments but make the comment confidential so that it's not publicly visible. Might be helpful to others.
11-06-2013

I'm not sure how related this may be, but sometimes I get an NPE during the run. This is however, very rare, much less frequent than the crash. $> /java/re/jdk/8/promoted/latest/binaries/linux-i586/bin/java -XX:+BackgroundCompilation -XX:MaxNodeLimit=300000 -XX:ReservedCodeCacheSize=240m -XX:+TieredCompilation -XX:+PrintCodeCache -jar /java/re/jdk/8/promoted/latest/binaries/linux-i586/jre/lib/ext/nashorn.jar run.js Richards: 2282 DeltaBlue: 2054 Crypto: java.lang.NullPointerException RayTrace: 533 EarleyBoyer: 397 RegExp: 309 Splay: 1769 NavierStokes: 1309 CodeCache: size=245760Kb used=43593Kb max_used=44773Kb free=202166Kb bounds [0xa82ae000, 0xaae96000, 0xb72ae000] total_blobs=11790 nmethods=11534 adapters=171 compilation: enabled
11-06-2013

@Chris: Sure, I can work on your system - if that is OK for you.
11-06-2013

Since this is my office machine, I didn't want to post info in the CR. Albert and I had an email discussion. I setup an account on the system for him and he did reproduce the problem there yesterday.
11-06-2013

You never mentioned which machine you are using. At least I didn't see it in any of the comments.
11-06-2013

In this case I'm using a promoted build, although I also see crashes with my private builds. Is there an reason you can't debug on the system I reproduced it on?
11-06-2013

Just as a general note, some bugs never reproduce on other systems except the one where the bug was initially found.
11-06-2013

Hi, I tried to reproduce the bug on a second system - without success. I tried on 3 different Ubuntu 32-bit systems; 200 runs of the v8 benchmarks ran without encountering the bug. To only use 2 cores I used the 'taskset' command. I am not quite sure how to proceed with this bug. Any help is very welcome.
11-06-2013

I've probably done 50 runs with fastdebug, but still no crashes. I noticed that not nearly as much code is generated with the fastdebug runs. I see 7973 methods compiled using 20m of codeache. With product builds I see 14688 methods compiled using about 58m of codecache. Because of this, the product build crashes don't seem to reproduce with fastdebug buidls.
09-06-2013

BTW, another problem I've seen recently, but is probably unrelated, is occasionally very bad results with RayTrace. As you can see in the log above, the score is close to 500. However, sometimes it gets in a mode where I consistently get scores around 19. I'll tried both b92 and b93 and consistently got the same results, and then suddenly the problem goes away.
09-06-2013

Actually I'm still seeing crashes, even with -XX:MaxNodeLimit=300000. I thought they went away, but now seem to be back. The three crashes below are with the latest JDK8, which is b93, but I also see problems with b92, which is what I originally filed this bug against. I haven't reproduced any crashes are asserts with fastdebug builds yet. $> /java/re/jdk/8/promoted/latest/binaries/linux-i586/bin/java -XX:MaxNodeLimit=300000 -XX:+BackgroundCompilation -XX:+TieredCompilation -XX:+PrintCodeCache -jar /java/re/jdk/8/promoted/latest/binaries/linux-i586/jre/lib/ext/nashorn.jar run.js # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (sharedRuntime.cpp:817), pid=14117, tid=3078286192 # guarantee(cb->is_adapter_blob() || cb->is_method_handles_adapter_blob()) failed: exception happened outside interpreter, nmethods and vtable stubs (1) # # JRE version: Java(TM) SE Runtime Environment (8.0-b93) (build 1.8.0-ea-b93) # Java VM: Java HotSpot(TM) Server VM (25.0-b34 mixed mode linux-x86 ) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /export/v8-bench/hs_err_pid14117.log Phoning home... Using server: 10.161.186.18, port 4711 # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Abort $> /java/re/jdk/8/promoted/latest/binaries/linux-i586/bin/java -XX:MaxNodeLimit=300000 -XX:+BackgroundCompilation -XX:+TieredCompilation -XX:+PrintCodeCache -jar /java/re/jdk/8/promoted/latest/binaries/linux-i586/jre/lib/ext/nashorn.jar run.js Richards: 2664 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xa930f384, pid=17357, tid=3078441840 # # JRE version: Java(TM) SE Runtime Environment (8.0-b93) (build 1.8.0-ea-b93) # Java VM: Java HotSpot(TM) Server VM (25.0-b34 mixed mode linux-x86 ) # Problematic frame: # J jdk.nashorn.internal.scripts.Script$deltablue._L691(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Z # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /export/v8-bench/hs_err_pid17357.log Phoning home... Using server: 10.161.186.18, port 4711 # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Abort $> /java/re/jdk/8/promoted/latest/binaries/linux-i586/bin/java -XX:MaxNodeLimit=300000 -XX:+BackgroundCompilation -XX:+TieredCompilation -XX:+PrintCodeCache -jar /java/re/jdk/8/promoted/latest/binaries/linux-i586/jre/lib/ext/nashorn.jar run.js Richards: 2117 DeltaBlue: 2047 Crypto: 1153 RayTrace: 507 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xaa220e97, pid=17391, tid=3078085488 # # JRE version: Java(TM) SE Runtime Environment (8.0-b93) (build 1.8.0-ea-b93) # Java VM: Java HotSpot(TM) Server VM (25.0-b34 mixed mode linux-x86 ) # Problematic frame: # J jdk.nashorn.internal.scripts.Script$earley_boyer$6._L3604(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /export/v8-bench/hs_err_pid17391.log Compiled method (c2) 150801 10109 4 jdk.nashorn.internal.scripts.Script$earley_boyer$6::_L3604 (286 bytes) total in heap [0xaa21ea08,0xaa28d4cc] = 453316 relocation [0xaa21ead4,0xaa220850] = 7548 constants [0xaa220860,0xaa220880] = 32 main code [0xaa220880,0xaa229700] = 36480 stub code [0xaa229700,0xaa22a25c] = 2908 oops [0xaa22a25c,0xaa22a5b4] = 856 metadata [0xaa22a5b4,0xaa22a790] = 476 scopes data [0xaa22a790,0xaa2880dc] = 383308 scopes pcs [0xaa2880dc,0xaa28ad1c] = 11328 dependencies [0xaa28ad1c,0xaa28ae78] = 348 handler table [0xaa28ae78,0xaa28d0e0] = 8808 nul chk table [0xaa28d0e0,0xaa28d4cc] = 1004 Phoning home... Using server: 10.161.186.18, port 4711 # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Abort
09-06-2013

Hi, I setup a 32-bit Ubuntu (13.04) system on my laptop and tried to reproduce the error - without success. I executed the benchmark around 50x without any error. I also tried to vary the code cache size. I am not quite sure how to proceed on fixing this issue. Any ideas? Best, Albert uname -a Linux anoll-TECRA-M11 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:24:54 UTC 2013 i686 i686 i686 GNU/Linux anoll@anoll-TECRA-M11:/export/anoll/benchmarks/v8$ /export/anoll/benchmarks/v8$ /export/anoll/jdk1.8.0/bin/java -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b92) Java HotSpot(TM) Server VM (build 25.0-b34, mixed mode) /export/anoll/jdk1.8.0/bin/java -Dengine=nashorn -XX:+TieredCompilation -XX:+PrintCodeCache -jar /export/anoll/jdk1.8.0/jre/lib/ext/nashorn.jar run.js
07-06-2013

Albert, yes we have many 32bit Ubuntu that used by emb-team. I will ask someone of them to contact with you.
06-06-2013

Is there any change to get access to a n Ubuntu-32 bit system?
05-06-2013

I got through 10 iterations with the product build using -XX:MaxNodeLimit=300000 with no problem.
04-06-2013

I'm using a 32-bit Ubuntu distro with two cores.
04-06-2013

Using -XX:MaxNodeLimit=300000 seems to fix the problem with fastdebug builds. I still need to verify that product builds work ok.
04-06-2013

Increase MaxNodeLimit: -XX:MaxNodeLimit=300000
04-06-2013

The following occurred on 2 out of 8 fastdebug runs with -XX:-VerifyDependencies, which is a bit less frequent then crashes with the product build (I think it crashed 5 out of 12 times). # Internal Error (/HUDSON/workspace/2-build-linux-i586/jdk8/4590/hotspot/src/share/vm/opto/node.cpp:71), pid=16895, tid=1846172528 # assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit # Internal Error (/HUDSON/workspace/2-build-linux-i586/jdk8/4590/hotspot/src/share/vm/opto/node.cpp:71), pid=16974, tid=1846508400 # assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit hs_err logs are attached.
04-06-2013

Try to use -XX:-VerifyDependencies
03-06-2013

I can't get results with fastdebug. Normally output is as follows: /java/re/jdk/8/promoted/latest/binaries/linux-i586/fastdebug/bin/java -XX:+BackgroundCompilation -XX:+TieredCompilation -jar /java/re/jdk/8/promoted/latest/binaries/linux-i586/jre/lib/ext/nashorn.jar run.js Richards: 2480 DeltaBlue: 2120 Crypto: 1136 RayTrace: 965 EarleyBoyer: 2239 RegExp: 396 Splay: 1674 NavierStokes: 1287 ---- Score (version 7): 1350 With fastdebug it never gets to RegExp: /java/re/jdk/8/promoted/latest/binaries/linux-i586/fastdebug/bin/java -XX:+BackgroundCompilation -XX:+TieredCompilation -jar /java/re/jdk/8/promoted/latest/binaries/linux-i586/jre/lib/ext/nashorn.jar run.js Richards: 855 DeltaBlue: 72.8 Crypto: 76.0 RayTrace: 43.8 EarleyBoyer: 103 I've tried a couple of times, and this was the result. Also notice that it runs about 20x slower with fastdebug, which seems excessive. BTW, I can run RegExp stand alone and it does complete it within a few minutes.
03-06-2013

Please, run with fastdebug VM. There are promoted fastdebug JDK.
03-06-2013