JVMDG315: JVM Requesting Heap dump file

Hi expert,
Using 10.2.04 Db with 11.5.10.2 on AIX 64 bit.
While running audit report which generate pdf format output gone in error....
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
..............................JVMDG318: Heap dump file written to /d04_testdbx/appltop/testcomn/admin/log/TEST_tajorn3/heapdump7545250.1301289300.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /d04_testdbx/appltop/testcomn/admin/log/TEST_tajorn3/javacore7545250.1301289344.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
Exception in thread "main" java.lang.OutOfMemoryError
     at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java(Compiled Code))
     at java.io.OutputStream.write(OutputStream.java(Compiled Code))
     at oracle.apps.xdo.common.log.LogOutputStream.write(LogOutputStream.java(Compiled Code))
     at oracle.apps.xdo.generator.pdf.PDFStream.output(PDFStream.java(Compiled Code))
     at oracle.apps.xdo.generator.pdf.PDFGenerator$ObjectManager.write(PDFGenerator.java(Compiled Code))
     at oracle.apps.xdo.generator.pdf.PDFGenerator$ObjectManager.writeWritable(PDFGenerator.java(Inlined Compiled Code))
     at oracle.apps.xdo.generator.pdf.PDFGenerator.closePage(PDFGenerator.java(Compiled Code))
     at oracle.apps.xdo.generator.pdf.PDFGenerator.newPage(PDFGenerator.java(Compiled Code))
     at oracle.apps.xdo.generator.ProxyGenerator.genNewPageWithSize(ProxyGenerator.java(Compiled Code))
     at oracle.apps.xdo.generator.ProxyGenerator.processCommand(ProxyGenerator.java(Compiled Code))
     at oracle.apps.xdo.generator.ProxyGenerator.processCommandsFromDataStream(ProxyGenerator.java(Compiled Code))
     at oracle.apps.xdo.generator.ProxyGenerator.close(ProxyGenerator.java:1230)
     at oracle.apps.xdo.template.fo.FOProcessingEngine.process(FOProcessingEngine.java:336)
     at oracle.apps.xdo.template.FOProcessor.generate(FOProcessor.java:1043)
     at oracle.apps.xdo.oa.schema.server.TemplateHelper.runProcessTemplate(TemplateHelper.java:5888)
     at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3593)
     at oracle.apps.pay.pdfgen.server.PayPDFGen.processForm(PayPDFGen.java:243)
     at oracle.apps.pay.pdfgen.server.PayPDFGen.runProgram(PayPDFGen.java:795)
     at oracle.apps.fnd.cp.request.Run.main(Run.java:161)
oracle.apps.pay.pdfgen.server.PayPDFGen
Program exited with status 1
No any error in db alert ...
Pleaes suggest where is prob..
Thanks in ADV

Hello,
* JVMST109: Insufficient space in Javaheap to satisfy allocation request
Exception in thread "main" java.lang.OutOfMemoryError
This is your problem. There is no enough memory. Change Java heap settings
Regards,
Shomoos
Edited by: shomoos.aldujaily on Mar 29, 2011 12:39 AM

Similar Messages

Heap dump file - Generate to a different folder

Hello,
When the AS Java iis generating the heap dump file, is it possible to generate it to a different folder rather than the standard one: /usr/sap// ?
Best regards,
Gonçalo Mouro Vaz

Hello Gonçalo
I don't think this is possible.
As per SAP Note 1004255;
On the first occurrence (only) of an OutOfMemoryError the JVM
will write a heap dump in the
/usr/sap/ directory
Can i ask why you would like it in a different folder?
Is it a space issue?
Thanks
Kenny

Analyse large heap dump file

Hi,
I have to analyse large heap dump file (3.6GB) from production environment. However if open it in eclipse mat, it is giving OutOfMemoryError. I tried to increase eclipse workbench java heap size as well. But it doesnt help. I also tried with visualVM as well. Can we split the heap dump file into small size? Or is there any way to set max heap dump file size for jvm options so that we collect reasonable size of heap dumps.
Thanks,
Prasad

Hi, Prasad
Have you tried open in 64-bit mat on a 64-bit platform with large heap size and CMS gc policy in MemoryAnalyzer.ini file ? the mat is good toolkit on analysing java heapdump file, if it cann't works, you can try Memory Dump Diagnostic for Java(MDD4J) in 64-bit IBM Support Assistant with large heap size.

Heap dump file size vs heap size

Hi,
I'd like to clarify my doubts.
At the moment we're analyzing Sun JVM heap dumps from Solaris platform.
Observation is that heap dump file is around 1,1GB while after loading to SAP Memory Analyzer it displays statistics: "Heap: 193,656,968" which as I understood is size of heap.
After I run:
jmap -heap <PID>
I get following information:
using thread-local object allocation
Parallel GC with 8 thread(s)
Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 3221225472 (3072.0MB)
   NewSize          = 2228224 (2.125MB)
   MaxNewSize       = 4294901760 (4095.9375MB)
   OldSize          = 1441792 (1.375MB)
   NewRatio         = 2
   SurvivorRatio    = 32
   PermSize         = 16777216 (16.0MB)
   MaxPermSize      = 67108864 (64.0MB)
Heap Usage:
PS Young Generation
Eden Space:
   capacity = 288620544 (275.25MB)
   used     = 26593352 (25.36139678955078MB)
   free     = 262027192 (249.88860321044922MB)
   9.213949787302736% used
From Space:
   capacity = 2555904 (2.4375MB)
   used     = 467176 (0.44553375244140625MB)
   free     = 2088728 (1.9919662475585938MB)
   18.27830779246795% used
To Space:
   capacity = 2490368 (2.375MB)
   used     = 0 (0.0MB)
   free     = 2490368 (2.375MB)
   0.0% used
PS Old Generation
   capacity = 1568669696 (1496.0MB)
   used     = 1101274224 (1050.2569427490234MB)
   free     = 467395472 (445.74305725097656MB)
   70.20434109284916% used
PS Perm Generation
   capacity = 67108864 (64.0MB)
   used     = 40103200 (38.245391845703125MB)
   free     = 27005664 (25.754608154296875MB)
   59.75842475891113% used
So I'm just wondering what is this "Heap" in Statistic Information field visible in SAP Memory Analyzer.
When I go to Dominator Tree view, I look at Retained Heap column and I see that they roughly sum up to 193,656,968.
Could someone put some more light on it?
thanks
Michal

Hi Michal,
that looks indeed very odd. First, let me ask which version do you use? We had a problem in the past where classes loaded by the system class loader were not marked as garbage collection roots and hence were removed. This problem is fixed in the current version (1.1). If it is version 1.1, then I would love to have a look at the heap dump and find out if it is us.
Having said that, this is what we do: After parsing the heap dump, we remove objects which are not reachable from garbage collection roots. This is necessary, because the heap dump can contain garbage. For example, the mark-sweep-compact of the old/perm generation leaves some dead space in the form of int arrays or java.lang.Object to win time during the compacting phase: by leaving behind dead objects, not every live object has to be moved which means not every object needs a new address. This is the kind of garbage we remove.
Of course, we do not remove objects kept alive only by weak or soft references. To see what memory is kept alive only through weak or soft references, one can run the "Soft Reference Statistics" from the menu.
Kind regards,
   - Andreas.
Edited by: Andreas Buchen on Feb 14, 2008 6:23 PM

Heap Dump file generation problem

Hi,
I've configured configtool to have these 2 parameters:
-XX:+HeapDumpOnOutOfMemoryError
-XX:+HeapDumpOnCtrlBreak
In my understanding, with these 2 parameters, the heap dump files will only be generated under 2 situations, ie, when out of memory occurred, or user manually click CLTR + BREAK in MMC.
1) Unfortunately, there are many heap dump files (9 in total) generated when none of the above situation occured. I couldnt find "OutOfMemoryError" in the default trace, nor the shallow heap size of those heap dump files are anywhere near the memory limit. The consequences are our server run out of disk space.
My question is, what are the other possibilities that heap dump file will be generated?
2) In the Memory Consumption graph (NWA (http://host:port/nwa) -> System Management -> Monitoring -> Java Systems Reports), out of memory error occurred when the memory usage is reaching about 80% of the allocated memory. What are the remaining 20% or so reserved for ?
Any help would be much appreciated.
Thanks.

Hi,
Having the -XX:+HeapDumpOnCtrlBreak option makes the VM trigger a heap dump, whenever a CTRL_BREAK event appears. The same event is used also to trigger a thread dump, an action you can do manually from the SAP Management Console, I think it is called "Dump stacks". So if there was someone triggering thread dumps for analysis of other types of problems, this has the side effect of writing also a heap dump.
Additionally, the server itself may trigger a thread dump (and by this also a heap dump if the option is present). It does this for example when a timeout appears during the start or stop of the server. A thread dump from such a moment allows us to see for example which service is unable to start.
Therefore, I would recommend that you leave only the -XX:+HeapDumpOnOutOfMemoryError, as long as you don't plan to trigger any heap dumps on your own. The latter will cause the VM to write a heap dump only once - on the first appearance of an OutOfMemoryError.
In case you need to trigger the heap dumps manually, leave the -XX:+HeapDumpOnCtrlBreak option for the moment of troubleshooting, but consider if you want to keep it afterwards.
If heap dumps were written because of an OutOfMemoryError you should be able to see this in the dev_server file in /usr/sap/<SID>/<inst>/work/ . Also there you should be able to see if indeed thread dumps were triggered (just search for "Full Thread ").
I hope this helps.
Regards,
Krum

Very Large Heap Dump

Hi,
I've to analyze a huge heap dump file (ca. 1GB).
I've tried some tools HAT, YourKit, Profiler4J... etc.)
Always an OutOfMemoryError occures.
My machine has 2GB physocal Memory and 3GB SwapSpace on a Dual Core Intel Processor with 2,6GHz
Is there a way to load the file on my machine or is there a tool which is able to load dump files partially?
ThanX ToX

1GB isn't very large :-) When you say you tried HAT, did you mean jhat? Just checking as jhat requires less memory than the original HAT. Also, did you include an option such as -J-mx1500m to increase the maximum heap for the tools that you tried? Another one to try is the HeapWalker tool in VisualVM. That does a better job than HAT/jhat with bigger heaps.

About jvm dump file EXCEPTION_ACCESS_VIOLATION (0xc0000005)

Hi folks,
Well, Unfortunately We are facing some issue which cause a Tomcat service is down in the following environment.
OS : Windows Server 2003 R2 SP2
TOMCAT version=5.5.23
JVM version=1.5.0_12
We try to find the cause using attached dump file which generated the one. but not sure why this issue happen in sometime(about once a month)
Could anyone know what could be wrong? i am baz, did you get to solve this same problem?
Thanks in advance...
---following a dump file
# An unexpected error has been detected by HotSpot Virtual Machine:
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c97be3e, pid=3608, tid=5976
# Java VM: Java HotSpot(TM) Client VM (1.5.0_12-b04 mixed mode, sharing)
# Problematic frame:
# C [ntdll.dll+0x2be3e]
--------------- T H R E A D ---------------
Current thread (0x02d88850): JavaThread "http-8080-Processor18" daemon [_thread_in_native, id=5976]
siginfo: ExceptionCode=0xc0000005, reading address 0xfffffff8
Registers:
EAX=0x00000380, EBX=0x00000000, ECX=0x0000037f, EDX=0x00000000
ESP=0x0383f068, EBP=0x0383f074, ESI=0x00570178, EDI=0x00800000
EIP=0x7c97be3e, EFLAGS=0x00010206
Top of Stack: (sp=0x0383f068)
0x0383f068: 00570000 00000581 02fb9000 0383f098
0x0383f078: 7c97b561 00570178 00000581 02fb9000
0x0383f088: 00570000 02f80000 02f80000 03800000
0x0383f098: 0383f0e0 7c97ba81 00000581 00fb9000
0x0383f0a8: 00000581 00570000 02fb9000 00000000
0x0383f0b8: 00000c08 02fbb000 0383f0dc 02f80000
0x0383f0c8: 00000000 00000000 02fb8e70 00000000
0x0383f0d8: 00000000 00000181 0383f1c4 7c97b646
Instructions: (pc=0x7c97be3e)
0x7c97be2e: 57 64 8b 14 8a 83 c2 08 3b f2 0f 84 d5 fe ff ff
0x7c97be3e: 0f b7 5a f8 3b 5d 0c 73 0b 8b 12 3b f2 75 f1 e9
Stack: [0x03800000,0x03840000), sp=0x0383f068, free space=252k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [ntdll.dll+0x2be3e]
C [ntdll.dll+0x2b561]
C [ntdll.dll+0x2ba81]
C [ntdll.dll+0x2b646]
C [MSVCRT.dll+0x1cef6]
C [net.dll+0x6a86]
J java.net.SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I
J java.net.SocketInputStream.read([BII)I
J org.apache.coyote.http11.InternalInputBuffer.fill()Z
J org.apache.coyote.http11.InternalInputBuffer.parseRequestLine()V
J org.apache.coyote.http11.Http11Processor.process(Ljava/io/InputStream;Ljava/io/OutputStream;)V
j org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Lorg/apache/tomcat/util/net/TcpConnection;[Ljava/lang/Object;)V+113
j org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(Ljava/net/Socket;Lorg/apache/tomcat/util/net/TcpConnection;[Ljava/lang/Object;)V+45
j org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt([Ljava/lang/Object;)V+102
j org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run()V+167
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
V [jvm.dll+0x87599]
V [jvm.dll+0xdfbb2]
V [jvm.dll+0x8746a]
V [jvm.dll+0x871c7]
V [jvm.dll+0xa2048]
V [jvm.dll+0x1110d8]
V [jvm.dll+0x1110a6]
C [MSVCRT.dll+0x2b530]
C [kernel32.dll+0x24829]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J java.net.SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I
J java.net.SocketInputStream.read([BII)I
J org.apache.coyote.http11.InternalInputBuffer.fill()Z
J org.apache.coyote.http11.InternalInputBuffer.parseRequestLine()V
J org.apache.coyote.http11.Http11Processor.process(Ljava/io/InputStream;Ljava/io/OutputStream;)V
j org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Lorg/apache/tomcat/util/net/TcpConnection;[Ljava/lang/Object;)V+113
j org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(Ljava/net/Socket;Lorg/apache/tomcat/util/net/TcpConnection;[Ljava/lang/Object;)V+45
j org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt([Ljava/lang/Object;)V+102
j org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run()V+167
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x02ee7820 JavaThread "File Reaper" daemon [_thread_blocked, id=4744]
0x02e23958 JavaThread "TP-Monitor" daemon [_thread_blocked, id=6000]
0x033159e8 JavaThread "TP-Processor4" daemon [_thread_in_native, id=7532]
0x033153c8 JavaThread "TP-Processor3" daemon [_thread_blocked, id=5932]
0x03305b28 JavaThread "TP-Processor2" daemon [_thread_blocked, id=6036]
0x02e2bd10 JavaThread "TP-Processor1" daemon [_thread_blocked, id=4816]
0x03102020 JavaThread "http-8080-Monitor" [_thread_blocked, id=4708]
0x031562f0 JavaThread "http-8080-Processor25" daemon [_thread_blocked, id=2668]
0x03155790 JavaThread "http-8080-Processor24" daemon [_thread_blocked, id=2092]
0x032d8410 JavaThread "http-8080-Processor23" daemon [_thread_blocked, id=5984]
0x03250808 JavaThread "http-8080-Processor22" daemon [_thread_blocked, id=7388]
0x02f80ba8 JavaThread "http-8080-Processor21" daemon [_thread_blocked, id=7956]
0x02f80048 JavaThread "http-8080-Processor20" daemon [_thread_blocked, id=8020]
0x02fc0448 JavaThread "http-8080-Processor19" daemon [_thread_in_native, id=1636]
=>0x02d88850 JavaThread "http-8080-Processor18" daemon [_thread_in_native, id=5976]
0x02ff2b20 JavaThread "http-8080-Processor17" daemon [_thread_blocked, id=2832]
0x02ff2058 JavaThread "http-8080-Processor16" daemon [_thread_blocked, id=7988]
0x03056468 JavaThread "http-8080-Processor15" daemon [_thread_blocked, id=2856]
0x031c55e0 JavaThread "http-8080-Processor14" daemon [_thread_blocked, id=2164]
0x02f7e808 JavaThread "http-8080-Processor13" daemon [_thread_blocked, id=3368]
0x0337ca28 JavaThread "http-8080-Processor12" daemon [_thread_blocked, id=2824]
0x0337c008 JavaThread "http-8080-Processor11" daemon [_thread_blocked, id=2820]
0x0315dc60 JavaThread "http-8080-Processor10" daemon [_thread_blocked, id=2888]
0x0325f408 JavaThread "http-8080-Processor9" daemon [_thread_blocked, id=5112]
0x02f24780 JavaThread "http-8080-Processor8" daemon [_thread_blocked, id=4692]
0x02ee4a48 JavaThread "http-8080-Processor7" daemon [_thread_blocked, id=2860]
0x02efcb80 JavaThread "http-8080-Processor6" daemon [_thread_blocked, id=5952]
0x031bbd58 JavaThread "http-8080-Processor5" daemon [_thread_blocked, id=7168]
0x031bb298 JavaThread "http-8080-Processor4" daemon [_thread_blocked, id=5940]
0x0335f910 JavaThread "http-8080-Processor3" daemon [_thread_blocked, id=2848]
0x03185b68 JavaThread "http-8080-Processor2" daemon [_thread_blocked, id=2672]
0x03339528 JavaThread "http-8080-Processor1" daemon [_thread_blocked, id=2800]
0x031e3e60 JavaThread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon [_thread_blocked, id=4752]
0x009080b0 JavaThread "Thread-1" [_thread_in_native, id=2152]
0x008d0998 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3040]
0x008cf6b8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=6844]
0x008bf4b8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=4916]
0x008a9ac0 JavaThread "Finalizer" daemon [_thread_blocked, id=1072]
0x008a8ee8 JavaThread "Reference Handler" daemon [_thread_blocked, id=1948]
0x00575ee0 JavaThread "main" [_thread_in_native, id=5488]
Other Threads:
0x008a7c98 VMThread [id=3224]
0x008d1dc8 WatcherThread [id=6332]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 36288K, used 1273K [0x06b50000, 0x092b0000, 0x092b0000)
eden space 32256K, 2% used [0x06b50000, 0x06c02b20, 0x08ad0000)
from space 4032K, 13% used [0x08ad0000, 0x08b5baf8, 0x08ec0000)
to space 4032K, 0% used [0x08ec0000, 0x08ec0000, 0x092b0000)
tenured generation total 483968K, used 17895K [0x092b0000, 0x26b50000, 0x26b50000)
the space 483968K, 3% used [0x092b0000, 0x0a429c30, 0x0a429e00, 0x26b50000)
compacting perm gen total 14336K, used 14104K [0x26b50000, 0x27950000, 0x2ab50000)
the space 14336K, 98% used [0x26b50000, 0x27916088, 0x27916200, 0x27950000)
ro space 8192K, 63% used [0x2ab50000, 0x2b060590, 0x2b060600, 0x2b350000)
rw space 12288K, 46% used [0x2b350000, 0x2b8f21b0, 0x2b8f2200, 0x2bf50000)
Dynamic libraries:
0x00400000 - 0x0040e000      D:\App\Tomcat\bin\tomcat5.exe
0x7c950000 - 0x7ca2a000      C:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c941000      C:\WINDOWS\system32\kernel32.dll
0x77e90000 - 0x77f20000      C:\WINDOWS\system32\USER32.dll
0x77ba0000 - 0x77be8000      C:\WINDOWS\system32\GDI32.dll
0x77de0000 - 0x77e8a000      C:\WINDOWS\system32\ADVAPI32.dll
0x77bf0000 - 0x77c8f000      C:\WINDOWS\system32\RPCRT4.dll
0x76e60000 - 0x76e73000      C:\WINDOWS\system32\Secur32.dll
0x77b40000 - 0x77b9a000      C:\WINDOWS\system32\MSVCRT.dll
0x7ca30000 - 0x7d218000      C:\WINDOWS\system32\SHELL32.dll
0x773d0000 - 0x77422000      C:\WINDOWS\system32\SHLWAPI.dll
0x76120000 - 0x7613d000      C:\WINDOWS\system32\IMM32.DLL
0x7f000000 - 0x7f009000      C:\WINDOWS\system32\LPK.DLL
0x75220000 - 0x75285000      C:\WINDOWS\system32\USP10.dll
0x77ca0000 - 0x77da3000      C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.3959_x-ww_D8713E55\comctl32.dll
0x6d640000 - 0x6d7dd000      D:\App\jre\jre1.5.0_12\bin\client\jvm.dll
0x76990000 - 0x769bb000      C:\WINDOWS\system32\WINMM.dll
0x71a60000 - 0x71a68000      C:\WINDOWS\system32\rdpsnd.dll
0x77ab0000 - 0x77ac1000      C:\WINDOWS\system32\WINSTA.dll
0x71ae0000 - 0x71b37000      C:\WINDOWS\system32\NETAPI32.dll
0x76a60000 - 0x76a6b000      C:\WINDOWS\system32\PSAPI.DLL
0x6d290000 - 0x6d298000      D:\App\jre\jre1.5.0_12\bin\hpi.dll
0x6d610000 - 0x6d61c000      D:\App\jre\jre1.5.0_12\bin\verify.dll
0x6d310000 - 0x6d32d000      D:\App\jre\jre1.5.0_12\bin\java.dll
0x6d630000 - 0x6d63f000      D:\App\jre\jre1.5.0_12\bin\zip.dll
0x6d4d0000 - 0x6d4e3000      D:\App\jre\jre1.5.0_12\bin\net.dll
0x71aa0000 - 0x71ab7000      C:\WINDOWS\system32\WS2_32.dll
0x71a90000 - 0x71a98000      C:\WINDOWS\system32\WS2HELP.dll
0x719c0000 - 0x71a01000      C:\WINDOWS\system32\mswsock.dll
0x5ba20000 - 0x5ba78000      C:\WINDOWS\system32\hnetcfg.dll
0x71980000 - 0x71988000      C:\WINDOWS\System32\wshtcpip.dll
0x76de0000 - 0x76e0b000      C:\WINDOWS\system32\DNSAPI.dll
0x76e80000 - 0x76e87000      C:\WINDOWS\System32\winrnr.dll
0x76e20000 - 0x76e4e000      C:\WINDOWS\system32\WLDAP32.dll
0x76e90000 - 0x76e95000      C:\WINDOWS\system32\rasadhlp.dll
0x68000000 - 0x68035000      C:\WINDOWS\system32\rsaenh.dll
VM Arguments:
jvm_args: -Dcatalina.home=D:\App\Tomcat -Dcatalina.base=D:\App\Tomcat -Djava.endorsed.dirs=D:\App\Tomcat\common\endorsed -Djava.io.tmpdir=D:\App\Tomcat\temp -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=D:\App\Tomcat\conf\logging.properties vfprintf -Xms512m -Xmx512m
java_command: <unknown>
Launcher Type: generic
Environment Variables:
PATH=C:\Program Files\Windows Resource Kits\Tools\;D:\App\Oracle\product\10.2.0\db_1\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\PROGRA~1\HITACHI\SERVER~1\SERVER~1\PROGRAM;C:\Program Files\Intel\DMIX;C:\Program Files\Common Files\Hitachi;C:\Program Files\Hitachi\JP1Base\bin;C:\Program Files\HITACHI\JP1AJS2\bin;C:\WINDOWS\hitachi;C:\Program Files\Hitachi\Script\Bin
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 15 Model 6 Stepping 4, GenuineIntel
--------------- S Y S T E M ---------------
OS: Windows Server 2003 family Build 3790 Service Pack 2
CPU:total 8 (cores per cpu 2, threads per core 2) family 15 model 6 stepping 4, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ht
Memory: 4k page, physical 2097151k(1993784k free), swap 4194303k(4194303k free)
vm_info: Java HotSpot(TM) Client VM (1.5.0_12-b04) for windows-x86, built on May 2 2007 02:07:59 by "java_re" with MS VC++ 6.0

Did you ever find the root cause of this?
We are also seeing this on various machines, all on 2003 server...
(his is an embedded Jetty engine)
Thanks!
# An unexpected error has been detected by HotSpot Virtual Machine:
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c97a36b, pid=900, tid=956
# Java VM: Java HotSpot(TM) Server VM (1.5.0_11-b03 mixed mode)
# Problematic frame:
# C [ntdll.dll+0x2a36b]
--------------- T H R E A D ---------------
Current thread (0x00968150): JavaThread "SharedThreadPool-8" [_thread_in_native, id=956]
siginfo: ExceptionCode=0xc0000005, reading address 0x320a0d2d
Registers:
EAX=0x2d0a0d32, EBX=0x003d0000, ECX=0x320a0d2d, EDX=0x00c02f90
ESP=0x1d03ef28, EBP=0x1d03f144, ESI=0x00c02f88, EDI=0x00000401
EIP=0x7c97a36b, EFLAGS=0x00010202
Top of Stack: (sp=0x1d03ef28)
0x1d03ef28: 00002000 00000000 7c979fd6 00968150
0x1d03ef38: 6d9d990d 00000000 00968150 1d03efd8
0x1d03ef48: 00000002 00c37700 0000000a 1d03f058
0x1d03ef58: 00968150 0096b500 0096b800 0096b848
0x1d03ef68: 0096bbf4 1d03fc04 00968150 00938670
0x1d03ef78: 045b9448 16183618 1d03f988 00d3d565
0x1d03ef88: 00000000 2d0a0d32 00000000 1d03f050
0x1d03ef98: 6db014b4 0096b838 00000000 1d03f090
Instructions: (pc=0x7c97a36b)
0x7c97a35b: 02 89 85 48 fe ff ff 8b 4a 04 89 8d f8 fe ff ff
0x7c97a36b: 8b 39 3b 78 04 0f 85 51 73 01 00 3b fa 0f 85 49
Stack: [0x1cf40000,0x1d040000), sp=0x1d03ef28, free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [ntdll.dll+0x2a36b]
C [MSVCRT.dll+0x1d08c]
C [net.dll+0x693c]
J java.net.SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J java.net.SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I
J java.net.SocketInputStream.read([BII)I
J org.mortbay.util.LineInput.fill()V
J org.mortbay.util.LineInput.fillLine(I)I
J org.mortbay.http.HttpConnection.handleNext()Z
J org.mortbay.http.HttpConnection.handle()V
J org.mortbay.http.SocketListener.handleConnection(Ljava/net/Socket;)V
J org.mortbay.util.ThreadedServer.handle(Ljava/lang/Object;)V
J org.mortbay.util.ThreadPool$PoolThread.run()V
v ~I2CAdapter
v ~StubRoutines::call_stub
<snip/>
VM Arguments:
jvm_args: -Xms256M -Xmx256M -Djava.library.path=lib -Dfms.home=C:\UGS\TEAMCE~1\TC2007~1.4\fsc -Dfms.config=fmsmaster_FSC_pnj1_vol02.xml -Dfsc.config=FSC_pnj1_vol02.xml -Dsun.net.client.defaultConnectTimeout=90000 -Dsun.net.client.defaultReadTimeout=90000 -Dcom.teamcenter.mld.logging.prefix=FSC_pnj1_vol02 exit
java_command: <unknown>
Launcher Type: generic
Environment Variables:
JAVA_HOME=C:\UGS\Teamcenter\Tc2007\install\install\jre
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Intel\DMIX;C:\Program Files\HITACHI\DynamicLinkManager\bin;C:\Program Files\HITACHI\DynamicLinkManager\lib;C:\Program Files\HDVM\HBaseAgent\bin;C:\Program Files\HDVM\HBaseAgent\util\bin;C:\Program Files\Common Files\Hitachi;C:\PROGRA~1\HITACHI\SERVER~1\SERVER~1\PROGRAM;lib
USERNAME=infodba
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 6 Model 15 Stepping 6, GenuineIntel
--------------- S Y S T E M ---------------
OS: Windows Server 2003 family Build 3790 Service Pack 2
CPU:total 4 (cores per cpu 2, threads per core 1) family 6 model 15 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2
Memory: 4k page, physical 2097151k(2097151k free), swap 4194303k(4194303k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_11-b03) for windows-x86, built on Dec 15 2006 00:54:53 by "java_re" with MS VC++ 6.0

Heap dumps on 32bit and 64 bit JVM

We are experiencing memory leak issues with one of our application deployed on JBOSS (SUN JVM 1.5, Win 32 OS). The application is already memory intensive and consumes the maximum heap (1.5 GB) allowed on a 32-bit JVM on Win32.
This leaves very few memory for heap dump and the JVM crashes whenever we try adding the heap dump flag (-agentlib:), with a "malloc error"..
Has anyone faced a scenario like this?
Alternatively for investigation purpose, we are trying to deploy it on a Windows X64 - but the vendor advises only to run on 32 bit JVM. Here is my question:
1) Can we run 32bit JVM on Windows 64? Even if we run, can i allocate more than 2 GB for heap memory?
2) I dont see the rational why we cannot run on 64bit JVM - because, JAVA programs are supposed to be 'platform-independent' and the application in form of byte code should be running no matter if it is a 32bit or 64-bit JVM?
3) Do we have any other better tools (except HPROF heapdumps) to analyze memory leaks - we tried using profiling tools but they too fail becos of very few memory available.
Any help is really appreciated! :-)
Anush
This topic has no replies.

Originally Posted by gleach1
I've done this a few time with ZCM 11.2
take special note that for each action in a bundle you can set a requirement - this is where you shold be specifying the appropriate architecture for the action, takes a bit longer to do but saves on the number of bundles and clogging up event logs with junk
modifying your existing actions in your bundles would probably be easier and make things cleaner to manage in the long term, this is more so the case when you have software that might only differ in the launch action depending on what program files folder it ends up in
Sorry to dig this late topic, but I've created a bundle which have an action that needs to be executed on 32 / 64 bits, each by an specific executable. Said,
(32 bits) ipxfer -s officescan.server -m 1 -p 8080 -c 63016
(64 bits) ipxfer_x64 -s officescan.server -m 1 -p 8080 -c 63016
So I added these two actions, marked each to have the correct arch ("Architecture / = / 32" or "Architecture / = / 64"), no fail on pre-requisite.
But now, every time one 32 bit machine executes the bundle, it gets an error:
Error starting "ipXfer_x64 -s officescan.server -m 1 -p 8080 -c 63016". Windows Error: This version of %1 is not compatible with the windows version in use. Please verify in your computer's system information if you need a x86 (32 bit) or x64 (64 bit) version of the program and contact software vendor
All the machines' CPU are 64 bits, but some of them have 32-bit Windows 7. These are the ones that are raising these errors.
I have other bundles restricted to 32/64 architectures, working correctly, but the restriction was created on the bundle level, not on the action level.
Sorry for the bad english.

JMap heap dump against gcore file

Hi,
We are running Java 1.5.0_06 on Solaris 9 on Sun v245, and are trying to analyze some memory issues we have been experiencing.
We have used Solaris gcore utility to take a complete core dump of the process. This dump file is ~1.8Gb.
We are now trying to create a heap dump from the core file using JMAP, so that we can use tools such as the Eclipse Memory Analyser (http://www.eclipse.org/mat) to examine our heap for memory issues.
However, we are having issues creating the heap dump, as JMAP appears to be running out of system memory (swap). The command we are running is "jmap -heap:format=b /usr/bin/java ms04Core.29918". We can run some other JMAP commands, such as "jmap -histo" against the core without encountering these issues. The server we are running on has 8Gb physical memory, but JMAP seems to crash when swap size reaches ~3.8Gb (according to Solaris PRSTAT command). The error returned by JMAP is -
Exception in thread "main" java.lang.OutOfMemoryError: requested 8192 bytes for jbyte in /BUILD_AREA/jdk1.5.0_06/hotspot/src/share/v
m/prims/jni.cpp. Out of swap space?
Would anyone have any ideas as to why we are seeing these issues?
Also, can anyone comment on if this approach makes sense as a way to analyze memory issues? Other suggestions would be welcome!
Thanks very much,
Adrian

Hi, we have solved this issue now - apparently this is a memory bug with the 1.5.0_06 version of JMAP. We installed a higher version JRE (5u15) and were able to complete the heap dump without issues.
Cheers,
Adrian

Jvm heap dump options

We have a memory leak occurring on our appserver (glassfish) and are having trouble pinpointing its cause, so I want to turn on some of the JVM heap dump options. I have turned on the following two:
-XX:-HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/heap_dump.hprofAre there any other options I can use to help resolve this? Also what will the dump output contain? Plain-text?
Thanks

a profiler comes to mind. But how do you know it is an actual memory leak? Are you getting out of memory exceptions?

Help with jrockit crashes (dump files) at MemSystem.getMoreTLAMemory

Hello,
We've recently started experiencing a lot of instability in one of our new deployments, generating core dumps as listed below.
The server in question is running jboss 3.2.2 with jrockit 1.4.2_03, on Red Hat Enterprise Linux WS release 3 (Taroon Update 3), with SQL Server 2000.
The dump file is listed below (I've actually listed 2). Any help or suggestions for research would be greatly appreciated. This is in our production environment, so I'm anxious for input. Thank you!
JRockit context dump produced after 0 days, 15:04:58 on Tue May 17 08:22:34 2005
If you see this dump, please send it, along with as much
information as you can on your system setup and the program
you were running, to [email protected]. Please include the
file jrockit.29470.dump from the current directory in the bug
report. Thank you.
A core file will be dumped into /usr/local/jboss-3.2.2/bin.
Please attach that file to your bug report.
Error Message: Null pointer exception in native code
Signal info : si_signo=11, si_code=2
Version : ari-24879-20031212-1523-linux-ia32
Threads / GC : Native Threads, GC strategy: gencon
: mmHeap->data = 0x9ef30000, mmHeap->top = 0xb6f30000
: nurseryStartAddress = 0xa1bdb1d0, nurseryEndAddress = 0xa60a92b0
: mmStartCompaction = 0xa0d30000, mmEndCompaction = 0xa8530000
Number CPUs : 4
Tot Phys Mem : 4187815936
OS version : Red Hat Enterprise Linux WS release 3 (Taroon Update 4)
Linux version 2.4.21-20.ELsmp ([email protected]) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42))
#1 SMP Wed Aug 18 20:46:40 EDT 2004
State : JVM is running
Command Line : -Djava.class.path=. -Dconfig_name=ciscotiger -Xms:384m -Xmx:384m -Xgc:gencon -Xns:52m -Djava.awt.headless
=true -Xmanagement -Djrockit.managementserver.port=17390 -Djava.class.path=/usr/local/jboss/bin/run.jar:/usr/local/jboss
/hhlib/log4jInitializer.jar:/usr/local/jboss/hhlib/log4j.jar:/usr/local/jrockit1.4.2/lib/tools.jar -Dsun.java.command=or
g.jboss.Main -c ciscotiger
Environment : JAVA_HOME=(null), java.home=/usr/local/jrockit-j2sdk1.4.2_03/jre, java.class.path=/usr/local/jboss/bin/ru
n.jar:/usr/local/jboss/hhlib/log4jInitializer.jar:/usr/local/jboss/hhlib/log4j.jar:/usr/local/jrockit1.4.2/lib/tools.jar
, java.library.path=/usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/jrockit:/usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386:
/usr/local/jrockit-j2sdk1.4.2_03/jre/../lib/i386
C Heap : Good; no memory allocations have failed
Registers:
EAX = b7413c39 EBX = 9479e0d4
ECX = 9479e1e0 EDX = 00000000
ESI = 09087488 EDI = 090fbda8
ESP = 9479e08c EIP = b7413c39
EBP = 9479e0a8 EFL = 00010286
CS = 0023 DS = 002b ES = 002b
SS = 002b FS = 003b GS = 0033
Stack:
9479e08c :b72eb7b5 00000000 9479e0b0 00000000 9479e0d4 9479e29c
9479e0a4 :9479e1e0 09087488 b72ebca3 00000000 3ff00000 9479e0d4
9479e0bc :b72ef852 09087488 9479e1c4 9479e114 b72eb571 09087488
9479e0d4 :00000000 00000000 b75a0000 09087488 9479e1c4 090fbda8
9479e0ec :b72ebe38 00000000 3ff00000 09087488 b72ebe27 9479e29c
9479e104 :09087488 9479e244 b72efed2 b73ec650 b73ec6e5 00000000
9479e11c :b72efb23 b73ec650 9479e1c4 9d9a8462 b72efb1a 9479e1e0
9479e134 :9479e244 9479e29c b72ed88d 9479e1e0 09087488 9479e1e0
9479e14c :9d9a8460 9479e1e0 9479e1c4 090fbda8 09087488 9479e1e0
9479e164 :9d9a8462 090fbda8 b72f0034 9d9a8463 9d9a8463 00000011
9479e17c :b738a732 9479e1e0 9479e1c4 090fbda8 b72eb265 9479e1e0
9479e194 :09087488 090fbda8 b72eb25a 9d9a8460 9479e1e0 00000000
9479e1ac :00000000 090fbda8 9479e358 00000001 9479e3bc b73515e7
9479e1c4 :9479e3f4 b738cc2c 00000000 09281018 9479e254 00000000
9479e1dc :b7469938 9d9a8460 00000000 00000003 00000000 00000000
9479e1f4 :000000d9 00000046 00000000 0000001c 00000000 b7415520
9479e20c :00000004 00000004 00000001 00000000 00000002 00004000
9479e224 :00000000 00000000 00000000 00000000 00000000 00000000
9479e23c :00000000 00000000 00000001 ffffffff 00000004 00000000
9479e254 :00000000 00000040 00000004 00000000 00000000 00000000
9479e26c :00000000 00000000 ffffffff 00000000 00000000 00000000
9479e284 :ffffffff 00000004 00000000 00000000 00000000 00000000
9479e29c :00000002 ffffffff 00000004 00000000 00000000 00000006
9479e2b4 :00000004 00000000 00000000 0000001c 00000001 00000000
9479e2cc :ffffffff 00000000 00000000 00000000 ffffffff 00000004
9479e2e4 :00000000 00000000 00000000 00000000 00000000 00000000
9479e2fc :00000000 00000000 00000000 00000000 00000000 00000000
9479e314 :00000000 00000000 00000000 b738e276 090fbda8 00000002
9479e32c :b738e27f 09087488 090fbda8 a6085018 b738e223 9479e3bc
9479e344 :00000000 b746a29c b7334029 9479e3f4 9479e454 0000000d
9479e35c :0000000e 0000006f 00000000 00000000 09281018 9479e3bc
9479e374 :9479e454 9dea082d b738e0ad 00000001 09281018 b746a29c
9479e38c :b733c5fd 9479e3bc 9479e454 9479e3c8 b733c665 9479e454
9479e3a4 :00000000 b746a29c 00000401 9479e45c 9479e454 00000001
9479e3bc :b738e1ca b745ffc4 9479e454 09281018 b738be42 b746a398
9479e3d4 :9479e454 9479e454 b738cc2c 00000000 09281018 b746a29c
9479e3ec :b7342012 b746a138 9479e3d8 b738cc2c 00000000 09281018
9479e404 :9479e454 a6080c50 b746a150 9479e454 00000000 00000005
9479e41c :985aafa2 a6080c50 a6080b00 9479e448 b7342089 9479e454
9479e434 :9479e4d4 00000005 b73420a5 00000080 00000000 00000401
9479e44c :b738bd91 09281018 9479e4d4 b738cc2c 00000000 09281018
9479e464 :09281018 b746a29c b745ffc4 080669c0 934c2810 a6084450
9479e47c :b732d95b 00000000 00000000 9479e4dc 09281018 9479e4d4
9479e494 :09281018 934c5391 b733b282 b746a29c 9479e4d4 a6081f68
9479e4ac :b733b2b1 00000000 00000080 00000000 a6081f68 080669c0
9479e4c4 :094bb8b0 00000006 00000000 00000000 00000000 b738cc2c
9479e4dc :00000000 09281018 a6081f38 a6081eb8 b746a29c 09281018
9479e4f4 :934c23a7 a6081388 b732efe8 080669c0 a6081eb8 00000000
9479e50c :b738dca9 091bcda4 094bb8b0 09281090 09281018 091bcda4
9479e524 :00000049 b738dca9 00000001 094bb8b0 09281090 b738dc8c
9479e53c :b73843dc 094bb8b0 0000066c 00000001 a4ed2c10 091bcda4
9479e554 :9479e570 a6085a30 09281018 9ff9c960 a607d4a0 00000001
9479e56c :9e170526 09281090 08113820 091bcda4 a607ca70 09281018
9479e584 :9e170578 0800da58 a6085a30 094bb8b0 a6085e58 9e1709d7
9479e59c :00000410 000001fe 96aaac21 00000001 00000011 00000010
9479e5b4 :a6085a30 a6085228 000000fd 0000010e 00000005 a6085990
9479e5cc :95bae7be a607ca70 a607c030 0000000c a6082ff8 00000000
9479e5e4 :9fe87740 00000001 b17a2308 a6090ec0 00000000 95bae4cf
9479e5fc :a607c030 b17a2308 00000000 a6090ec0 9fe86228 00000000
9479e614 :95badeda a607c030 b17a2308 a6090ec0 b17a2308 a0918198
9479e62c :b17a2308 9f4f0a58 a607b800 a6090ec0 00000000 a607b818
9479e644 :a60909e0 95bad4bb a607b800 b17a2308 a6090ec0 9fe86228
9479e65c :b17a2308 9f4f0a58 a6090ec0 00000000 a607b800 a6090998
9479e674 :00000000 00000006 9fe86228 9fe86228 95bad030 9fe82050
9479e68c :b21c97d0 b21c9970 94b4c7e4 94b4c7e4 95ba441e 9fe82050
9479e6a4 :a4dda960 9f0de780 00000001 a41b3420 9fe82050 b17a1440
9479e6bc :a07658a0 a0a7b6e8 9ff6d9c0 b21c97d0 b21c97d0 9ff6d9c0
9479e6d4 :00000000 a5bed0f8 b21c98d0 b21c98d0 a04fb540 9f0edba0
9479e6ec :a8de2b48 00005c2f b2221e20 b2221dd0 00000002 b2221d60
9479e704 :b2221d10 00000000 b2221dd0 00000002 b21c9930 00000001
9479e71c :b21c9950 00000001 b21c9950 00000000 00000001 b21c9950
9479e734 :00000001 b21c9970 00000001 b21c9970 00000001 00000000
9479e74c :934c39d7 a5fe3b58 a18016d0 a60612d0 9f0de780 a6061320
9479e764 :a095f6b0 a095f6b0 a095f6b0 a095f6b0 a095f6b0 a095f6b0
9479e77c :a095f6b0 a095f6f8 a18016e8 9f0de798 a091b358 a091b358
9479e794 :a17e99d8 a17e99d8 b17a2308 a17e99d8 a17e99d8 a17e99d8
9479e7ac :a17e99d8 a095f6f8 a0765878 b1a0cf98 a6061da8 a5c8df68
9479e7c4 :a095f6f8 b221c648 b221c660 a1801ac0 b221c678 9f3363b0
9479e7dc :b221c690 9f3363e0 b221c6a8 a4dda6a8 b221c6c0 b221c6d8
9479e7f4 :b221c6f0 b221c708 a4dda960 b221c720 9f3363e0 00000012
9479e80c :b221c750 b221c768 00000000 a095f6b0 b1a0d178 b221c780
9479e824 :9f3366b8 b221c798 b221c7b0 00000001 b221c810 b221c7c8
9479e83c :b221c7e0 b221c7f8 00000001 b221c768 b221c828 b221c840
9479e854 :b221c858 00000000 a17efcd0 9f336748 9f336760 b221c870
9479e86c :b221c888 b221c8a0 b221c8b8 a8f0f990 a6020c10 00000000
9479e884 :00000008 b221c918 b21c98e8 b21c9900 b21c9918 b221c930
Code:
b7413b39 :00000000 83000000 3cd904ec 246cd924 24548b08 24448b10
b7413b51 :db2adb0c 8bc1de28 db142444 242cd938 c304c483 00000000
b7413b69 :00000000 00000000 00000000 00000000 00000000 83000000
b7413b81 :3cd904ec 246cd924 24548b08 24448b10 db28db0c 8be9de2a
b7413b99 :db142444 242cd938 c304c483 00000000 00000000 00000000
b7413bb1 :00000000 00000000 00000000 83000000 3cd904ec 246cd924
b7413bc9 :24548b08 24448b10 db2adb0c 8bc9de28 db142444 242cd938
b7413be1 :c304c483 00000000 00000000 00000000 00000000 00000000
b7413bf9 :00000000 83000000 3cd904ec 246cd924 24548b08 24448b10
b7413c11 :db28db0c 8bf9de2a db142444 242cd938 c304c483 00000000
b7413c29 :00000000 00000000 24448b00 c328db04 0824548b 1024448b
b7413c41 :002244dd 00b838db c3000000 d904ec83 6cd9243c 448b0824
b7413c59 :548b0c24 28db1024 f1d92adb 1424448b 2cd938db 04c48324
b7413c71 :000000c3 40b7413b 80b7413b c0b7413b 00b7413b 32b7413c
b7413c89 :4db7413c 39b7413c 00b7413c 00000000 00000000 83000000
b7413ca1 :7ab73ec9 00b73ec9 00000000 77000000 6bb73ec9 00b73ec9
b7413cb9 :00000000 69000000 63b73ec9 5fb73ec9 4cb73ec9 49b73ec9
b7413cd1 :3ab73ec9 37b73ec9 2db73ec9 2bb73ec9 25b73ec9 23b73ec9
b7413ce9 :1eb73ec9 1bb73ec9 11b73ec9 0eb73ec9 05b73ec9 02b73ec9
b7413d01 :f3b73ec9 f0b73ec8 e6b73ec8 e4b73ec8 deb73ec8 dab73ec8
b7413d19 :c7b73ec8 c5b73ec8 c0b73ec8 00b73ec8 00000000 bd000000
b7413d31 :b4b73ec8 00b73ec8 00000000 b2000000 abb73ec8 a8b73ec8
Loaded modules:
(* denotes the module causing the exception)
0x08048000-0x0804cd66 /usr/local/jrockit-j2sdk1.4.2_03/bin/java
0xb75cd000-0xb75d9931 /lib/tls/libpthread.so.0
0xb75ab000-0xb75cbe5f /lib/tls/libm.so.6
0xb75a8000-0xb75a9e23 /lib/libdl.so.2
0xb7470000-0xb75a1eaf /lib/tls/libc.so.6
0xb75e9000-0xb75fdc8b /lib/ld-linux.so.2
0xb725b000-0xb740f4ef /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/jrockit/libjvm.so
0xb6f33000-0xb6f3d2df /lib/libnss_files.so.2
0x9e20d000-0x9e21cfa5 /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/libverify.so
0x9d739000-0x9d7589cf /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/libjava.so
0x9d719000-0x9d72a0eb /lib/libnsl.so.1
0x9c1e4000-0x9c1e7133 /lib/libnss_dns.so.2
0x9c1d2000-0x9c1e079f /lib/libresolv.so.2
0x9a47b000-0x9a47e5c1 /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/libioser12.so
Java Thread ID = 0x00002c80, Name = Thread-50
Thread Stack Trace:
at jrockit/vm/MemSystem.getMoreTLAMemory(Native Method)@0x9e1704f0
at jrockit/vm/MemSystem.getMoreTLAMemoryWrapper(Native Method)@0x9e170578
at jrockit/vm/MemSystem.allocArray2(Native Method)@0x9e1709d7
at java/lang/StringBuffer.append(Optimized Method)@0x96aaac21
at com/hartehanks/ntouch/ui/web/taglib/ntwtag/FormDateFieldTag.createNumberPullDown(FormDateFieldTag.java:420)@0x95b
ae7be
at com/hartehanks/ntouch/ui/web/taglib/ntwtag/FormDateFieldTag.createNumberPullDown(FormDateFieldTag.java:382)@0x95b
ae4cf
at com/hartehanks/ntouch/ui/web/taglib/ntwtag/FormDateFieldTag.createDatePullDownAtPosition(FormDateFieldTag.java:32
9)@0x95badeda
at com/hartehanks/ntouch/ui/web/taglib/ntwtag/FormDateFieldTag.doEndTag(FormDateFieldTag.java:184)@0x95bad4bb
at webforms/outboundPanel_jsp._jspx_meth_ntwtag_datefield_0(outboundPanel_jsp.java:895)@0x95bad030
at webforms/outboundPanel_jsp._jspService(outboundPanel_jsp.java:606)@0x95ba441e
at org/apache/jasper/runtime/HttpJspBase.service(HttpJspBase.java:137)@0x981a2c94
at javax/servlet/http/HttpServlet.service(HttpServlet.java:853)@0x97fc787e
at org/apache/catalina/core/ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)@0x981a881c
at org/apache/catalina/core/ApplicationDispatcher.doInclude(ApplicationDispatcher.java:575)@0x981a76b2
at org/apache/catalina/core/ApplicationDispatcher.include(ApplicationDispatcher.java:498)@0x981a734c
at org/apache/jasper/runtime/JspRuntimeLibrary.include(JspRuntimeLibrary.java:822)@0x981a6228
at webforms/webEntry_jsp._jspService(webEntry_jsp.java:394)@0x9766960a
at org/apache/jasper/runtime/HttpJspBase.service(HttpJspBase.java:137)@0x981a2c94
at javax/servlet/http/HttpServlet.service(HttpServlet.java:853)@0x97fc787e
at org/apache/catalina/core/ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)@0x981a881c
at org/apache/catalina/core/ApplicationDispatcher.doInclude(ApplicationDispatcher.java:575)@0x981a76b2
at org/apache/catalina/core/ApplicationDispatcher.include(ApplicationDispatcher.java:498)@0x981a734c
at org/apache/jasper/runtime/JspRuntimeLibrary.include(JspRuntimeLibrary.java:822)@0x981a6228
at entry/displayEntry_jsp._jspService(displayEntry_jsp.java:251)@0x97665ed2
at org/apache/jasper/runtime/HttpJspBase.service(HttpJspBase.java:137)@0x981a2c94
at javax/servlet/http/HttpServlet.service(HttpServlet.java:853)@0x97fc787e
at org/apache/catalina/core/ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)@0x981a881c
at org/apache/catalina/core/ApplicationDispatcher.doForward(ApplicationDispatcher.java:432)@0x981aa46d
at org/apache/catalina/core/ApplicationDispatcher.forward(ApplicationDispatcher.java:356)@0x981aa07c
at com/hartehanks/ntouch/ui/web/util/misc/UrlHelper.forward(UrlHelper.java:44)@0x9302db2f
at com/hartehanks/ntouch/ui/web/outbound/servlet/OutboundBrowserServlet.openNextQueueItem(OutboundBrowserServlet.jav
a:546)@0x93ca4a5d
at com/hartehanks/ntouch/ui/web/outbound/servlet/OutboundBrowserServlet.doAction(OutboundBrowserServlet.java:121)@0x
93027d4c
at com/hartehanks/ntouch/ui/web/servlet/WebServlet.doPost(WebServlet.java:56)@0x93027343
at com/hartehanks/ntouch/ui/web/servlet/WebServlet.doGet(WebServlet.java:36)@0x930272a3
at javax/servlet/http/HttpServlet.service(HttpServlet.java:740)@0x9598975e
at javax/servlet/http/HttpServlet.service(HttpServlet.java:853)@0x97fc787e
at org/apache/catalina/core/ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)@0x981a2752
at org/apache/catalina/core/ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)@0x981a2474
at org/apache/catalina/core/StandardWrapperValve.invoke(StandardWrapperValve.java:256)@0x981a1094
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)@0x9a
9efd3d
at org/apache/catalina/core/StandardPipeline.invoke(StandardPipeline.java:480)@0x9a9efb94
at org/apache/catalina/core/ContainerBase.invoke(ContainerBase.java:995)@0x9a9efb35
at org/apache/catalina/core/StandardContextValve.invoke(StandardContextValve.java:191)@0x981a0a8f
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)@0x9a
9efd3d
at org/jboss/web/tomcat/security/JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:220)@0x981a06c1
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)@0x9a
9efd6d
at org/apache/catalina/authenticator/AuthenticatorBase.invoke(AuthenticatorBase.java:553)@0x982884f7
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)@0x9a
9efd6d
at org/apache/catalina/valves/CertificatesValve.invoke(CertificatesValve.java:246)@0x9828757c
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)@0x9a
9efd6d
at org/jboss/web/tomcat/tc4/statistics/ContainerStatsValve.invoke(ContainerStatsValve.java:76)@0x982873a6
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)@0x9a
9efd6d
at org/apache/catalina/core/StandardPipeline.invoke(StandardPipeline.java:480)@0x9a9efb94
at org/apache/catalina/core/ContainerBase.invoke(ContainerBase.java:995)@0x9a9efb35
at org/apache/catalina/core/StandardContext.invoke(StandardContext.java:2416)@0x982872b3
at org/apache/catalina/core/StandardHostValve.invoke(StandardHostValve.java:180)@0x98282496
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)@0x9a
9efd3d
at org/apache/catalina/valves/ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)@0x98282182
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)@0x9a
9efd6d
at org/apache/catalina/valves/ErrorReportValve.invoke(ErrorReportValve.java:172)@0x98281f22
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)@0x9a
9efd6d
at org/jboss/web/tomcat/security/SecurityAssociationValve.invoke(SecurityAssociationValve.java:65)@0x982817ab
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)@0x9a
9efd6d
at org/apache/catalina/valves/AccessLogValve.invoke(AccessLogValve.java:577)@0x98280d4b
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)@0x9a
9efd6d
at org/apache/catalina/core/StandardPipeline.invoke(StandardPipeline.java:480)@0x9a9efb94
at org/apache/catalina/core/ContainerBase.invoke(ContainerBase.java:995)@0x9a9efb35
at org/apache/catalina/core/StandardEngineValve.invoke(StandardEngineValve.java:174)@0x98280182
at org/apache/catalina/core/StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)@0x9a
9efd3d
at org/apache/catalina/core/StandardPipeline.invoke(StandardPipeline.java:480)@0x9a9efb94
at org/apache/catalina/core/ContainerBase.invoke(ContainerBase.java:995)@0x9a9efb35
at org/apache/coyote/tomcat4/CoyoteAdapter.service(CoyoteAdapter.java:223)@0x9a9eb97b
at org/apache/jk/server/JkCoyoteHandler.invoke(JkCoyoteHandler.java:263)@0x9a9eb62d
at org/apache/jk/common/HandlerRequest.invoke(HandlerRequest.java:360)@0x9a9e99ce
at org/apache/jk/common/ChannelSocket.invoke(ChannelSocket.java:604)@0x9a9e96ba
at org/apache/jk/common/ChannelSocket.processConnection(ChannelSocket.java:562)@0x9a9e8bb0
at org/apache/jk/common/SocketConnection.runIt(ChannelSocket.java:679)@0x9a9e8aa1
at org/apache/tomcat/util/threads/ThreadPool$ControlRunnable.run(ThreadPool.java:619)@0x9afc5818
at java/lang/Thread.run(Unknown Source)@0x9d86ac81
at java/lang/Thread.startThreadFromVM(Unknown Source)@0x9e176fe3
--- End of stack trace
If you see this dump, please send it, along with as much
information as you can on your system setup and the program
you were running, to [email protected]. Please include the
file jrockit.29470.dump from the current directory in the bug
report. Thank you.
A core file will be dumped into /usr/local/jboss-3.2.2/bin.
Please attach that file to your bug report.
===== END DUMP ===============================================================
===== BEGIN DUMP =============================================================
JRockit context dump produced after 0 days, 02:50:57 on Mon May 16 14:20:48 2005
If you see this dump, please send it, along with as much
information as you can on your system setup and the program
you were running, to [email protected]. Please include the
file jrockit.12873.dump from the current directory in the bug
report. Thank you.
A core file will be dumped into /usr/local/jboss-3.2.2/bin.
Please attach that file to your bug report.
Error Message: Null pointer exception in native code
Signal info : si_signo=11, si_code=2
Version : ari-24879-20031212-1523-linux-ia32
Threads / GC : Native Threads, GC strategy: gencon
: mmHeap->data = 0x9ef30000, mmHeap->top = 0xb6f30000
: nurseryStartAddress = 0xa1625540, nurseryEndAddress = 0xb5a6ca48
: mmStartCompaction = 0xb5730000, mmEndCompaction = 0xb6f30000
Number CPUs : 4
Tot Phys Mem : 4187815936
OS version : Red Hat Enterprise Linux WS release 3 (Taroon Update 4)
Linux version 2.4.21-20.ELsmp ([email protected]) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42))
#1 SMP Wed Aug 18 20:46:40 EDT 2004
State : JVM is running
Command Line : -Djava.class.path=. -Dconfig_name=ciscotiger -Xms:384m -Xmx:384m -Xgc:gencon -Xns:52m -Djava.awt.headless
=true -Xmanagement -Djrockit.managementserver.port=17390 -Djava.class.path=/usr/local/jboss/bin/run.jar:/usr/local/jboss
/hhlib/log4jInitializer.jar:/usr/local/jboss/hhlib/log4j.jar:/usr/local/jrockit1.4.2/lib/tools.jar -Dsun.java.command=or
g.jboss.Main -c ciscotiger
Environment : JAVA_HOME=(null), java.home=/usr/local/jrockit-j2sdk1.4.2_03/jre, java.class.path=/usr/local/jboss/bin/ru
n.jar:/usr/local/jboss/hhlib/log4jInitializer.jar:/usr/local/jboss/hhlib/log4j.jar:/usr/local/jrockit1.4.2/lib/tools.jar
, java.library.path=/usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/jrockit:/usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386:
/usr/local/jrockit-j2sdk1.4.2_03/jre/../lib/i386
C Heap : Good; no memory allocations have failed
Registers:
EAX = b7413c39 EBX = 9b8e6b18
ECX = 9b8e6c24 EDX = 00000000
ESI = 9a12b1e0 EDI = 92ad4028
ESP = 9b8e6ad0 EIP = b7413c39
EBP = 9b8e6aec EFL = 00010286
CS = 0023 DS = 002b ES = 002b
SS = 002b FS = 003b GS = 0033
Stack:
9b8e6ad0 :b72eb7b5 00000000 9b8e6af4 00000000 9b8e6b18 9b8e6ce0
9b8e6ae8 :9b8e6c24 9a12b1e0 b72ebca3 00000000 3fe80000 9b8e6b18
9b8e6b00 :b72ef852 9a12b1e0 9b8e6c08 ad672238 b72eb571 9a12b1e0
9b8e6b18 :00000000 00000000 b72e0000 9a12b1e0 9b8e6c08 92ad4028
9b8e6b30 :b72ebe38 00000000 3fe80000 9a12b1e0 b72ebe27 9b8e6ce0
9b8e6b48 :9a12b1e0 9b8e6c88 b72efed2 b73ec650 b73ec6e5 00000000
9b8e6b60 :b72efb23 b73ec650 9b8e6c08 9154d3e4 b72efb1a 9b8e6c24
9b8e6b78 :9b8e6c88 9b8e6ce0 b72ed88d 9b8e6c24 9a12b1e0 9b8e6c24
9b8e6b90 :9154d3e2 9b8e6c24 9b8e6c08 92ad4028 9a12b1e0 9b8e6c24
9b8e6ba8 :9154d3e4 92ad4028 b72f0034 9154d3e8 9154d3e8 00000011
9b8e6bc0 :00000041 9b8e6c24 9b8e6c08 92ad4028 b72eb265 9b8e6c24
9b8e6bd8 :9a12b1e0 92ad4028 b72eb25a 9154d3e2 9b8e6c24 00000000
9b8e6bf0 :00000000 92ad4028 9b8e6d9c 00000001 9b8e6e00 b73515e7
9b8e6c08 :9b8e6e38 b738cc2c 00000000 08d859e0 8bafd804 00000000
9b8e6c20 :b7469938 9154d3e2 00000000 00000006 00000000 00000000
9b8e6c38 :000000d9 00000005 00000000 9daa20fc 00000000 b7415520
9b8e6c50 :00000004 00000004 00000004 00000000 00000002 00004000
9b8e6c68 :00000000 00000000 00000000 00000000 00000000 00000000
9b8e6c80 :00000000 00000000 00000001 ffffffff 00000004 00000000
9b8e6c98 :00000000 00000040 00000004 00000000 00000000 00000000
9b8e6cb0 :00000000 00000000 ffffffff 00000000 00000000 00000000
9b8e6cc8 :ffffffff 00000004 00000000 00000000 00000000 00000000
9b8e6ce0 :00000002 ffffffff 00000004 00000000 00000000 ffffffff
9b8e6cf8 :00000004 00000000 00000000 9daa20fc 00000004 00000000
9b8e6d10 :ffffffff 00000000 00000000 00000000 ffffffff 00000004
9b8e6d28 :00000000 00000000 00000000 00000000 00000000 00000000
9b8e6d40 :00000000 00000000 00000000 00000000 00000000 00000000
9b8e6d58 :00000000 00000000 00000000 b738e276 92ad4028 00000002
9b8e6d70 :b738e27f 9a12b1e0 92ad4028 9b8e6ddc b738e223 9b8e6e00
9b8e6d88 :00000000 b746a29c b7334029 9b8e6e38 9b8e6e98 00000054
9b8e6da0 :00000055 00000068 00000000 00000000 08d859e0 9b8e6e00
9b8e6db8 :9b8e6e98 00000000 b738e0ad 00000001 08d859e0 b746a29c
9b8e6dd0 :b733c5fd 9b8e6e00 9b8e6e98 9b8e6e0c b733c665 9b8e6e98
9b8e6de8 :00000000 b746a29c 000003fb 9b8e6ea0 9b8e6e98 00000000
9b8e6e00 :b738e1ca b745ffc4 9b8e6e98 08d859e0 b738be42 b746a398
9b8e6e18 :9b8e6e98 9b8e6e98 b738cc2c 00000000 08d859e0 b746a29c
9b8e6e30 :b7342012 b746a138 9b8e6e1c b738cc2c 00000000 08d859e0
9b8e6e48 :9b8e6e98 b5a4dd98 b746a150 9b8e6e98 00000000 00000000
9b8e6e60 :00000000 00000068 b75a5180 9b8e6e8c b7342089 9b8e6e98
9b8e6e78 :9b8e6f18 0000000c b73420a5 00000080 00000000 000003fb
9b8e6e90 :b738bd91 08d859e0 9b8e6f18 b738cc2c 00000000 08d859e0
9b8e6ea8 :08d859e0 b746a29c b745ffc4 08066980 00000000 00000001
9b8e6ec0 :b732d95b 00000000 00000000 9b8e6f20 08d859e0 9b8e6f18
9b8e6ed8 :08d859e0 00000017 b733b282 b746a29c 9b8e6f18 b59eb368
9b8e6ef0 :b733b2b1 00000000 00000080 00000000 00000000 08066980
9b8e6f08 :08e8fa70 00000002 00000000 00000000 00000000 b738cc2c
9b8e6f20 :00000000 08d859e0 00000000 8c63ca39 b746a29c 08d859e0
9b8e6f38 :b5a0c3f8 b738dca9 b732efe8 08066980 b59eb368 b738dc8c
9b8e6f50 :b738dca9 092707ec 08e8fa70 08d85a58 08d859e0 092707ec
9b8e6f68 :b5a0c390 b59ee900 00000001 b59ee900 8c6326b0 092707ec
9b8e6f80 :b73843dc 08e8fa70 b738dc8c 08d859e0 00000001 092707ec
9b8e6f98 :9b8e6fb4 9f26bda8 08d85a58 9fce40e0 00000017 00000000
9b8e6fb0 :9e170526 08d85a58 08113820 092707ec b5a0c6b0 b5a0c350
9b8e6fc8 :9e170578 0800da58 9f26bda8 08e8fa70 b5a0c6f0 9e1709d7
9b8e6fe0 :00000028 0000000c 8b6910f5 b5a0c688 9f266168 9f26bda8
9b8e6ff8 :0000000c b5a0c5a8 08d859e0 00000000 00000067 9fcca590
9b8e7010 :00000000 00000001 00000040 0000000b b5a0c520 b5a0c618
9b8e7028 :08d859e0 9fb4c200 8b696ce3 9f26bd30 08d859e0 b5a0c338
9b8e7040 :8bfb9328 442ed487 b5a0c520 b5a0c520 b5a0c468 b5a0c520
9b8e7058 :b5a0c520 b5a0c438 b5a0c338 b5a316d8 b59e6950 00000000
9b8e7070 :b5a0c438 b5a0c438 b59e8410 8b68887e b59e6950 b5a0c438
9b8e7088 :b59e6b38 a40a40a8 08d859e0 08d859e0 b5a0c438 0000000c
9b8e70a0 :b5a0c438 b5a0c2e0 b59ee7d8 a01e0090 00000000 00000002
9b8e70b8 :00000000 00000062 b5a316d8 00000004 b59ee818 b59ee7f8
9b8e70d0 :00000003 00000000 00000004 00000000 b59e7100 00000003
9b8e70e8 :00000004 a01df4d0 ffffffff 00000000 00000000 9fca21a8
9b8e7100 :00000000 00000001 9fccaf68 00000000 00000003 00000000
9b8e7118 :b59e6ba0 b59e71d8 00000000 00000003 a01df3e0 b59e6b38
9b8e7130 :00000000 ffffffff b59e6950 b59e6d80 b59e6950 08d859e0
9b8e7148 :b59e6ba0 8b68f679 b59e6b38 b59e6998 0000000a a139bbd0
9b8e7160 :9f0fa140 b59e6a98 b59e6ba0 a139bbd0 ffffffff b59e6968
9b8e7178 :b5a316d8 b59e6a98 b59e6b38 b59e6950 b59e6b50 00000000
9b8e7190 :8c5d858d b59e6b38 00000000 8bfb7688 00000000 ffffffff
9b8e71a8 :b5a316d8 b59e6b50 b59e6b38 b59e6950 b59e6950 b5a316d8
9b8e71c0 :93d88c69 b59e6b38 93d88c20 b59e6b38 96b068a7 b59e6b38
9b8e71d8 :b5a30890 b59e6458 8aa52387 9f0fa158 b7377ddb 696e2da2
9b8e71f0 :9f0fa140 00000002 a139bbd0 0000000c 0000002a 08d859e0
9b8e7208 :b5a30798 00000000 a139bbd0 08d85a58 9f0fa140 9f0fa140
9b8e7220 :b5a30848 b5a30810 00000000 afca7e68 b5a300d0 9f0fa048
9b8e7238 :9f0fa158 00000001 b7377e51 08d85a58 9f0fa048 9f0fa158
9b8e7250 :96b071b9 9f0fa158 9f0fa048 00000000 96b07177 9f0fa158
9b8e7268 :9f0fa048 08d859e0 9b8e728c 96b0712b 9f0fa158 9f0fa048
9b8e7280 :9e171dd8 9f0fa158 9f0fa048 96b07110 b7377c0d 9b8e741b
9b8e7298 :00000008 00000002 9b8e732c 08d85a58 968cbe98 99a55670
9b8e72b0 :b7377d20 08d85a58 99a55670 99a50080 b7351329 99a55670
9b8e72c8 :9b8e72e0 08d85a58 00000001 00000001 00000004 00000012
Code:
b7413b39 :00000000 83000000 3cd904ec 246cd924 24548b08 24448b10
b7413b51 :db2adb0c 8bc1de28 db142444 242cd938 c304c483 00000000
b7413b69 :00000000 00000000 00000000 00000000 00000000 83000000
b7413b81 :3cd904ec 246cd924 24548b08 24448b10 db28db0c 8be9de2a
b7413b99 :db142444 242cd938 c304c483 00000000 00000000 00000000
b7413bb1 :00000000 00000000 00000000 83000000 3cd904ec 246cd924
b7413bc9 :24548b08 24448b10 db2adb0c 8bc9de28 db142444 242cd938
b7413be1 :c304c483 00000000 00000000 00000000 00000000 00000000
b7413bf9 :00000000 83000000 3cd904ec 246cd924 24548b08 24448b10
b7413c11 :db28db0c 8bf9de2a db142444 242cd938 c304c483 00000000
b7413c29 :00000000 00000000 24448b00 c328db04 0824548b 1024448b
b7413c41 :002244dd 00b838db c3000000 d904ec83 6cd9243c 448b0824
b7413c59 :548b0c24 28db1024 f1d92adb 1424448b 2cd938db 04c48324
b7413c71 :000000c3 40b7413b 80b7413b c0b7413b 00b7413b 32b7413c
b7413c89 :4db7413c 39b7413c 00b7413c 00000000 00000000 83000000
b7413ca1 :7ab73ec9 00b73ec9 00000000 77000000 6bb73ec9 00b73ec9
b7413cb9 :00000000 69000000 63b73ec9 5fb73ec9 4cb73ec9 49b73ec9
b7413cd1 :3ab73ec9 37b73ec9 2db73ec9 2bb73ec9 25b73ec9 23b73ec9
b7413ce9 :1eb73ec9 1bb73ec9 11b73ec9 0eb73ec9 05b73ec9 02b73ec9
b7413d01 :f3b73ec9 f0b73ec8 e6b73ec8 e4b73ec8 deb73ec8 dab73ec8
b7413d19 :c7b73ec8 c5b73ec8 c0b73ec8 00b73ec8 00000000 bd000000
b7413d31 :b4b73ec8 00b73ec8 00000000 b2000000 abb73ec8 a8b73ec8
Loaded modules:
(* denotes the module causing the exception)
0x08048000-0x0804cd66 /usr/local/jrockit-j2sdk1.4.2_03/bin/java
0xb75cd000-0xb75d9931 /lib/tls/libpthread.so.0
0xb75ab000-0xb75cbe5f /lib/tls/libm.so.6
0xb75a8000-0xb75a9e23 /lib/libdl.so.2
0xb7470000-0xb75a1eaf /lib/tls/libc.so.6
0xb75e9000-0xb75fdc8b /lib/ld-linux.so.2
0xb725b000-0xb740f4ef /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/jrockit/libjvm.so
0xb6f33000-0xb6f3d2df /lib/libnss_files.so.2
0x9e20d000-0x9e21cfa5 /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/libverify.so
0x9d73a000-0x9d7599cf /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/libjava.so
0x9d71a000-0x9d72b0eb /lib/libnsl.so.1
0x9ca5f000-0x9ca62133 /lib/libnss_dns.so.2
0x9ca4d000-0x9ca5b79f /lib/libresolv.so.2
0x98b9b000-0x98b9e5c1 /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/libioser12.so
0x8ee3a000-0x8f104b5c /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/libawt.so
0x8ede6000-0x8ee38017 /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/libmlib_image.so
0x8edd3000-0x8edd95f3 /usr/X11R6/lib/libXp.so.6
0x8ed82000-0x8edce8ab /usr/X11R6/lib/libXt.so.6
0x8ed74000-0x8ed805e3 /usr/X11R6/lib/libXext.so.6
0x8ed6f000-0x8ed72e87 /usr/X11R6/lib/libXtst.so.6
0x8ec90000-0x8ed6b1c3 /usr/X11R6/lib/libX11.so.6
0x8ec88000-0x8ec8eefb /usr/X11R6/lib/libSM.so.6
0x8ec71000-0x8ec84223 /usr/X11R6/lib/libICE.so.6
0x8dc9c000-0x8dd5529c /usr/local/jrockit-j2sdk1.4.2_03/jre/lib/i386/libfontmanager.so
Java Thread ID = 0x00000f80, Name = Thread-11
Thread Stack Trace:
at jrockit/vm/MemSystem.getMoreTLAMemory(Native Method)@0x9e1704f0
at jrocki

We will try these in test...
Initially we were experiencing JVM hangs (where the JBoss process simply stopped responding) on one of our production servers with 142_05, but no core dumps were ever produced. So we moved the application to a different server that has been running some other deployments without problems (different versions of our codebase and use cases however) to rule out hardware/external configuration issues.
On this server, we did get core dumps.
So, we're not sure if they are dying for unrelated reasons (seems unlikely) or if the _05 just did not generate core dumps properly???
take care!
Shell

AD4J: Unable to start Heap Dump due to OS Error

When Java 'Heap Dump' is requested, the following message is shown:
Unable to start Heap Dump due to OS Error.
Details of the monitored JDK and application server are given below:
JDK: Sun JDK 1.4.2_08 on Solaris 9
Application Server: WebLogic 8.1 SP4
1. What could be the possible cause? No errors are logged in jamserv/logs/error_log. Is there any way to enable detailed logging?
2. Each time the heap dump is requested, a file of the format heapdump<n> gets created in /tmp (e.g. /tmp/heapdump12.txt). If you see the file, it contains the following:
a) a line containing summary of the heap usage, and
b) stack traces of all the threads
Thanks!

Wrong Forum?

IBM Heap Dump command line utilities

Hello,
I am looking for command line parameter for IBM Heap dump location in configtool. I know we can set using environment variable IBM_HEAPDUMPDIR but I would like to get some command utilities to set it in configtool.
Thanks in Advance !

Hi,
The JVM checks each of the following locations for existence and write-permission, then stores the Heapdump in the first one that is available.
The location that is specified using the file suboption on the triggered -Xdump:heap agent.
The location that is specified by the IBM_HEAPDUMPDIR environment variable, if set (_CEE_DMPTARG on z/OS(R)).
The current working directory of the JVM processes.
The location that is specified by the TMPDIR environment variable, if set.
The /tmp directory. On Windows(R), C:\temp.
Details : http://publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/index.jsp?topic=/com.ibm.java.doc.diagnostics.142j9/html/contents.html
Regards,
Sandeep

EM Agent get restarted on heap dump generation with jmap command

Hi all,
To find the cause of OutOfMemory error we are generating heap dump of perticular JVM process by using the command "jmap -dump:format=b,file=heap.bin <pid>".
But when we excute this command, then our all the other jvm process get crashed and it also crashed emagent process.
I would like to know the reason why these processes and specially emagent process
get crashed.
Regards,
$

Hi Michal,
that looks indeed very odd. First, let me ask which version do you use? We had a problem in the past where classes loaded by the system class loader were not marked as garbage collection roots and hence were removed. This problem is fixed in the current version (1.1). If it is version 1.1, then I would love to have a look at the heap dump and find out if it is us.
Having said that, this is what we do: After parsing the heap dump, we remove objects which are not reachable from garbage collection roots. This is necessary, because the heap dump can contain garbage. For example, the mark-sweep-compact of the old/perm generation leaves some dead space in the form of int arrays or java.lang.Object to win time during the compacting phase: by leaving behind dead objects, not every live object has to be moved which means not every object needs a new address. This is the kind of garbage we remove.
Of course, we do not remove objects kept alive only by weak or soft references. To see what memory is kept alive only through weak or soft references, one can run the "Soft Reference Statistics" from the menu.
Kind regards,
- Andreas.
Edited by: Andreas Buchen on Feb 14, 2008 6:23 PM

JRockit Crashes with empty dump file.

---Symptom:
JRockit creates an empty dump file and dies without fully starting
Dump file looks like this:
     [user@computer some_dir]$ cat jrockit.25058.dump
     ===== BEGIN DUMP ===============================
     [user@computer some_dir]$
---Cause:
ulimit -s 2048
This limits the stack size which apparently causes problems for JRockit.
This limit had been set to workaround a known issue in the Sun JVM.
---Workaround:
Use system default stack size or a size larger than 2048.
---Environment:
Java:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1032-linux-ia32, Native Threads, GC strategy: parallel)
OS:
Linux DL580 2.4.21-15.ELsmp #1 SMP Thu Apr 22 00:18:24 EDT 2004 i686 i686 i386 GNU/Linux

Bandas,
The crash most likely happens because you have very little memory left on your system.
In the dump you can find the following message:
"C Heap : 3 memory allocations have failed"
This indicates that three malloc have failed internally. Given additional information in the dump it looks like an allocation did fail during garbage collection internally within the JVM that caused this crash. We have been working at improving the error message on these kinds of complete out of memory situations.
The best thing you can do is to reduce the java-heap size which will make more native memory available.
Another thing you can try if you haven't is to boot up windows in /3GB mode which will give JRockit access to the an additional 1GB of memory. (Your machine seem to have 3GB+ memory so booting Windows with the /3GB switch will allow JRockit to take advantage of that memory)
I hope this helps

JVMDG315: JVM Requesting Heap dump file

Similar Messages

Maybe you are looking for