An unexpected error has been detected by HotSpot Virtual Machine:

Spark reported this around the same second that WIldfire reported the second bit…

./Spark: line 300: 8895 Aborted “$app_java_home/bin/java” -client -Dinstall4j.jvmDir="$app_java_home" -Dexe4j.moduleName="$prg_dir/$prg" “-Dappdir=$prg_dir/” -Dsun.java2d.noddraw=true $INSTALL4J_ADD_VM_PARAMS -classpath “$local_classpath” com.install4j.runtime.Launcher launch org.jivesoftware.Spark true false “$prg_dir/logs/error.log” “$prg_dir/logs/output.log” true true false “” true true 0 0 “” 20 20 “Arial” “0,0,0” 8 500 “version 2.0.8” 20 40 “Arial” “0,0,0” 8 500 -1 “$@”

  1. An unexpected error has been detected by HotSpot Virtual Machine:

  1. SIGSEGV (0xb) at pc=0x4028a0a2, pid=6530, tid=2564545456

  1. Java VM: Java HotSpot™ Server VM (1.5.0_06-b05 mixed mode)

  2. Problematic frame:

  3. V


T H R E A D -


Current thread (0x98a0c3c8): JavaThread “CompilerThread0” daemon

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000000

Registers:

EAX=0x00000000, EBX=0x406fa7f0, ECX=0x00000000, EDX=0xb92a2580

ESP=0x98dbc424, EBP=0x98dbc468, ESI=0xb96bf648, EDI=0x0000005d

EIP=0x4028a0a2, CR2=0x00000000, EFLAGS=0x00010296

Top of Stack: (sp=0x98dbc424)

0x98dbc424: 00000042 00000028 00000002 98dbc450

0x98dbc434: 0002c000 400ed4d8 4026d64a 00000000

0x98dbc444: a07b4a70 00000000 b805c998 b92a2590

0x98dbc454: 00000002 00000028 406fa7f0 406a3008

0x98dbc464: b805c998 98dbc4a8 40289e0d b92a2580

0x98dbc474: b805c998 00000063 98dbc7e0 b96bf648

0x98dbc484: b805c998 00000000 00000000 ffffffff

0x98dbc494: 00000005 00000005 406fa7f0 98dbcd90

Instructions: (pc=0x4028a0a2)

0x4028a092: 08 83 ec 0c 8b 42 04 8b 04 b8 89 45 d8 8b 4d d8

0x4028a0a2: 8b 00 51 ff 90 c0 00 00 00 89 c6 89 04 24 e8 db

Stack: [0x98d3d000,0x98dbe000), sp=0x98dbc424, free space=509k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

V

V

V

V

V

V

V

V

V

V

V

V

C

Current CompileTask:

opto:1685 ! org.jivesoftware.wildfire.handler.PresenceSubscribeHandler.process(Lorg/xmpp/pa cket/Packet;)V (388 bytes)

I read the threads on this dump, however what I am confused on is that nothing has changed on this server in months…

Hi Jeff,

this is a JRE issue, you could try to use the latest JRE or create in wildfire/bin/ a file named “.hotspot_compiler” with the content “exclude org/jivesoftware/wildfire/handler/PresenceSubscribeHandler process” and restart Wildfire.

In nohup.out, stdout.log or stderr.log the JRE should log that it will not compile this method.

LG

LG,

I trust your information, and will implement what you stated, however can you tell me exactly what this is going to accomplish for me? is this going to stop presence updates? Also, could this be one of the reasons Iam seeing the errors in my other thread on tokenizer?

on the file, all I need to do is to create the . file, and then restart wildfire? I do not have to change or create any pointers in the wildfire executable?

Many thanks,

Jeff

is the line supposed to read:

exclude org/jivesoftware/wildfire/handler/PresenceSubscribeHandlerprocess ??

the line you wrote wrapped in my browser,

Message was edited by: jeff_garner

Hi Jeff,

the JVM usually compiles methods on the fly (interpreted mode), after some (1500 ?) executions it will compile and optimize the code, probalby also inline some methods, to store the resulting native code for further usage. So it seems that your server had to handle a lot of subscriptions.

The “-Xint” option will force “interpreted mode” for the whole java application which is quite slow, while the

“.hotspot_compiler” file will limit “interpreted mode” for the method which did cause trouble.

“exclude class method” is the right format:

exclude org/jivesoftware/wildfire/handler/PresenceSubscribeHandler process

LG

Thanks LG.

I have written the file and am scheduling time to take the service offline for maintanence. That will allow me to look at updating the Java version, put the file into play, and maybe even look at 3.1.1 Wildfire version.

Many Thanks,

Jeff