Out of memory error in IBM JVM

Hi i am using websphere application server's dyna cache for getting performance optimiztion in my application.
I am able to load values into the cache using the command cache api in the dyna cache.When i clear the cache for loading another set of values the cache gets cleared but still ,while loading the second set of values i get an out of memory error
The dynacache is an distributed map
i want to know whether the error is due to improper garbage collection
on this map,if so help me to overcome this
The JVM configuration are as follows
Min 256mb
Max 768mb
I have a total of 1Gb ram

Maybe your program's memory usage is rubbing against the upper limit, and something about the latest JVM caused it to break through.
Try using the command line parameter -mx500m (for 500 megs or whatever amount you neeed)

Similar Messages

Out of memory error with last jvm

Hi,
i have written a program which run perfectly under java jre 1.4.2_03. But when I test it with the last java jre 1.4.2_05, I get a java.lang.OutOfMemoryError. Is there something different in the JVM?
I have log out the garbage collector for the both JVM and it shows me that with the last java release the memory allocated is fully increasing. Trying to allocate more heap memory to the jvm do not change anything.
Have any one an idea? or encounterd this problem?
here is the listing from java142_03:
[GC 511K->93K(1984K), 0.0158240 secs]
[GC 17915K->16431K(25580K), 0.0235110 secs]
[GC 18095K->16550K(25580K), 0.0187630 secs]
[GC 18214K->16511K(25580K), 0.0095240 secs]
[GC 18175K->16541K(25580K), 0.0100360 secs]
[GC 18205K->16598K(25580K), 0.0085490 secs]
[GC 18261K->16677K(25580K), 0.0088590 secs]
Here is the listing from java142_05
[GC 8652K->8347K(9012K), 0.0165860 secs]
[Full GC 8347K->8347K(9012K), 0.5212970 secs]
[GC 9435K->8789K(15068K), 0.0167740 secs]
[GC 9877K->9222K(15068K), 0.0187010 secs]
[GC 10310K->9654K(15068K), 0.0184040 secs]
[GC 10742K->10084K(15068K), 0.0196390 secs]
[GC 11172K->10511K(15068K), 0.0203420 secs]
[Full GC 14101K->14101K(15196K), 0.7232510 secs]
[GC 15643K->14695K(25200K), 0.2429610 secs]
[GC 22448K->22157K(25200K), 0.0621640 secs]
[GC 23757K->23582K(25200K), 0.0506020 secs]
[GC 25182K->24892K(26608K), 0.0644240 secs]
[Full GC[Unloading class sun.reflect.GeneratedMethodAccessor16]
24892K->24892K(26608K), 1.1170130 secs]
[GC 27695K->27186K(44560K), 0.4203820 secs]
[GC 42058K->41883K(44816K), 0.0457160 secs]
[Full GC 41883K->40172K(44816K), 2.3119850 secs]
[GC 44268K->43989K(65088K), 0.0923610 secs]
[GC 48085K->47342K(65088K), 0.1587490 secs]
[GC 51438K->50693K(65088K), 0.1573160 secs]
[GC 54789K->54044K(65088K), 0.1593800 secs]
[GC 58140K->57396K(65088K), 0.1578900 secs]
[Full GC 61492K->60747K(65088K), 2.5820780 secs]
[Full GC 65087K->64298K(65088K), 2.6938250 secs]
[Full GC 65087K->64944K(65088K), 2.6716200 secs]
[Full GC 65087K->63781K(65088K), 3.4285840 secs]
[Full GC 64664K->64504K(65088K), 2.6915320 secs]
[Full GC 64504K->64504K(65088K), 2.6798100 secs]

Maybe your program's memory usage is rubbing against the upper limit, and something about the latest JVM caused it to break through.
Try using the command line parameter -mx500m (for 500 megs or whatever amount you neeed)

Out of Memory Error While deploying as EAR file

Hai,
I was trying to deploy an EAR file of size 63 MB which inturn containing about 60 EJB.jars. No WARs. application.xml has all the entries for the JARs. While I am deploying it is giving Out of Memory Error. Is there any way to tweak this problem. I am using my own hand written java application which uses the SunONE deployment APIs for deployment. Can u please tell how to tackle this problem. I am running my application through a batch file which uses jdk1.4.
Please help me regarding this issue.

You can set the initial heap size and maximum heap size for the JVM, either in the app-server admin console, or maybe in one of your scripts. You look-up the syntax!...
I had this error yesterday. I too had run out of memory (150Mb). You simply need to allocate more to the app-server.

ERROR [B3108]: Unrecoverable out of memory error during a cluster operation

We are using Sun Java(tm) System Message Queue Version: 3.5 SP1 (Build 48-G). We are using two JMS servers as a cluster.
But we frequently getting the out of memory issue during the cluster operation.
Messages also got queued up in the Topics. Eventhough listeners have the capability to reconnect with the Server after the broker restarting, usually we are restarting consumer instances to get work this.
Here is detailed log :
Jan 5 13:45:40 polar1-18.eastern.com imqbrokerd_cns-jms-18[8980]: [ID 478930 daemon.error] ERROR [B3108]: Unrecoverable out of memory error during a cluster operation. Shutting down the broker.
Jan 5 13:45:57 polar1-18.eastern18.chntva1-dc1.cscehub.com imqbrokerd: [ID 702911 daemon.notice] Message Queue broker terminated abnormally -- restarting.
Expecting your attention on this.
Thanks

Hi,
If you do not use any special cmdline options, how do you configure your servers/
brokers to 1 Gb or 2 Gb JVM heap ?
Regarding your question on why the consumers appear to be connecting to just
one of the brokers -
How are the connection factories that the consumers use configured ?
Is the connection factory configured using the imqAddressList and
imqAddressListBehavior attributes ? Documentation for this is at:
http://docs.sun.com/source/819-2571/ref_adminobj_props.html#wp62463
imqAddressList should contain a list of brokers (i.e. 2 for you) in the cluster
e.g.
mq://server1:7676/jms,mq://server2:7676/jms
imqAddressListBehavior defines how the 2 brokers in the above list are picked.
The default is in the order of the list - so mq://server1:7676/jms will always be
picked by default. If you want random behavior (which will hopefully even out the
load), set imqAddressListBehavior to RANDOM.
regards,
-i
http://www.sun.com/software/products/message_queue/index.xml

Thread: Out of memory error

I'm running a program that reads a file of more than 20k lines. Each line of this file is being processed by a thread. Sometimes the program is being halted with the out of memory error.
What can I do to solve this problem ? Is it better to change the logic of this program and instead of calling a new thread for each line, call few threads to be responsible of processing multiple lines ?
The current java version is 1.4.2.13. Upgrading it to the most recent version can solve the problem ?
I'm running it with the following configuration:
"-Xms1024m -Xmx2048m -XX urvivorRatio=10"
Thanks a lot,
Marcos.

Indeed this design is flawed. It is an old system that came to my hands and now I have to fix some bugs on it.
What is the difference between calling thousand of threads and having this backport of concurrent to take care of it ? I mean, isn't the jvm responsible for managing the both cases ?
Using the backport of concurrent and defining a limited size thread pool, what will happen if the number of lines in the file is greater than the size of this pool ?
Do you have an example or a link to where I can get a good example on how to use it ?
Thanks for helping!

Out of Memory Error in iplanet 6.1

While starting iplanet 6.1 sp2 in HP-UX 11.00 , out of memory error occurs. Value for JVM heapsize is set to min 128 MB and Max of 512 MB. Tried changing both the values to 512 MB, still the error occurs.
Please revert with any solution.

Please find the values of JVM HeapSIze and HP-UX process and address space limits.
JVM Heap size has been changed to
Min 128MB
Max 2GB
max_thread_proc 2048
maxdsiz 1073741824
maxssiz 401604608
maxtsiz 1073741824
After the modification of the above changes , out of memory errors occurs.Find the logfile below.
[21/Feb/2005:09:37:31] failure ( 8528): for host 163.38.174.17 trying to POST /wect/servlets/com.citicorp.treasury.westerneurope.maintenance.PageLinksServlet, service-j2ee reports: StandardWrapperValve[PageLinksServlet]: WEB2792: Servlet.service() for servlet PageLinksServlet threw exception
javax.servlet.ServletException: WEB2664: Servlet execution threw an exception
at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:793)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:322)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:209)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)
at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:161)
at com.iplanet.ias.web.WebContainer.service(WebContainer.java:578)
----- Root Cause -----
java.lang.OutOfMemoryError
[21/Feb/2005:09:45:04] warning ( 8528): HTTP3039: terminating with 6 sessions st
ill in progress
[21/Feb/2005:09:45:04] failure ( 8528): CORE3189: Restart functions not called since 6 sessions still active
Please suggest.

Out of Memory Error in Java Agents running in lotus notes

I have a java agent running inside lotus notes jvm. It runs fine for some days but after some days start giving out of memory error and terminates.
I need to restart agent manager in notes to enable java agent running. Is there a way to catch out of memory error so that on its catch i could restart agent manager.
Regards,
Saitu

Dear Peter,
The agent is written in java and
I need to know a way to enter catch block of 'OUTOFMEMORYERROR'.
My whole code is in a try block with two catches, one for outofmemoryerror and another for exception. When outofmemory error occurs control passes to the exception catch and not outofmemoryerror catch.
Since out of memory is an error and not an exception, is there a way to catch it or run some code when out of memory occurs.
Regards,
Saitu

JNI and Out of Memory errors

Hi,
At my job, we seem to have a memory leak related to JNI. We know we
have a memory leak because we keep getting Out of Memory errors even
after increasing the maximum heap size to more than 256 megs. And we
know that this is the application that is eating up all the system
memory.
We are running under Windows 2000, with both JDK 1.3.0 and JDK 1.4.1.
We tried looking at the problem under JProbe, but it shows a stable
Java heap (no problems, except that the Windows task manager shows it
growing and growing...)
I tried a strip down version, where I set the max heap size to 1 Meg,
and print out the total memory, memory used, and maximum memory used at
a 5 sec interval.
Memory used = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory().
Well, I let that strip down version running for about a day. The
maximum memory used has stabilized to about 1.1 Meg, and has not
increased. The current memory used increases until it gets to some
threshold, then it decreases again. However, the Windows task manager
shows the memory increasing -- and currently it is at 245 Megs!
In the lab, the behavior we see with the Windows task manager is as
follows:
1. Total memory used in the system increases until some threshold.
2. Then it goes back down by about 100 Megs.
3. This cycle continues, but at each cycle the memory goes back down
less and less, until the app crashes.
Now, our theory is that JNI is consuming all this memory (maybe we are
using JNI wrong). That's the only explanation we can come up with to
explain what we have seen (Java showing an OK heap, but the task
manager showing it growing, until crashing).
Does that make sense? Can the new operator throw an Out of Memory
error if the system does not have enough memory to give it, even if
there is still free heap space as far as the Runtime object is
concerned? Does the Runtime object figures objects allocated through
JNI methods into the heap used space?
Note that I know the task manager is not a reliable indicator.
However, I don't think a Java app is supposed to runaway with system
memory -- the problem is not simply that the Java app is consuming too
much memory, but that it seems to always want more memory. Besides, we
do get the Out of Memory error.
Thanks for your help,
Nicolas Rivera

Hi,
there are two sources of memory leakage in JNI:
- regular leaks in c/c++ code;
- not released local/global references of java objects in JNI.
I think that the first issue in not a problem for you. The second is more complex. In your JNI code you should check
- how many local references alive you keep in your code as their number is restricted (about 16 and can be enlarged). The good style is not to store local references but keep only global.
- any local reference accepted from java call in JNI are released by JVM. You should release local references you created in JNI and also global references.
- do not use a large number of java object references. Each new reference gets new memory in JVM. Try to reuse refences.
I guess that is your problem.
Vitally

Getting HeapDump on out of memory error when executing method through JNI

I have a C++ code that executes a method inside the jvm through the JNI.
I have a memory leak in my java code that results an out of memory error, this exception is caught in my C++ code and as a result the heap dump is not created on the disk.
I am running the jvm with
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=C:\x.hprof
Any suggestions?
Thanks

I'll rephrase it then.
I have a java class named PbsExecuter and one static method in it ExecuteCommand.
I am calling this method through JNI (using CallStaticObjectMethod). sometimes this method causes the jvm to throw OutOfMemoryError and I would like to get a heap dump on the disk when this happens in order to locate my memory leak.
I've started the jvm with JNI_CreateJavaVM and I've put two options inside the JavaVMInitArgs that is used to create the Jvm. -XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath=C:\x.hprof
which supposed to create a heap dump on the disk when OutOfMemoryError occurs.
Normally if I would execute normal java code, when this exception would occur and I wouldn't catch it the Jvm would crash and the heap dump would be created on the disk.
Since I need to handle errors in my C++ code I am use ExceptionOccured() and extracts the exception message from the exception it self and write it.
For some reason when I execute this method through JNI it doesn't create the dump.

Out of memory error when writing large file

I have the piece of code below which works fine for writing small files, but when it encounters much larger files (>80M), the jvm throws an out of memory error.
I believe it has something to do with the Stream classes. If I were to replace my PrintStream reference with the System.out object (which is commented out below), then it runs fine.
Anyone else encountered this before?
     print = new PrintStream(new FileOutputStream(new File(a_persistDir, getCacheFilename()),
                                                            false));
//      print = System.out;
          for(Iterator strings = m_lookupTable.keySet().iterator(); strings.hasNext(); ) {
               StringBuffer sb = new StringBuffer();
               String string = (String) strings.next();
               String id = string;
               sb.append(string).append(KEY_VALUE_SEPARATOR);
               Collection ids = (Collection) m_lookupTable.get(id);
               for(Iterator idsIter = ids.iterator(); idsIter.hasNext();) {
                    IBlockingResult blockingResult = (IBlockingResult) idsIter.next();
                    sb.append(blockingResult.getId()).append(VALUE_SEPARATOR);
               print.println(sb.toString());
               print.flush();
} catch (IOException e) {
} finally {
     if( print != null )
          print.close();
}

Yes, my first code would just print the strings as I got them. But it was running out of memory then as well. I thought of constructing a StringBuffer first because I was afraid that the PrintStream wasn't allocating the memory correctly.
I've also tried flushing the PrintStream after every line is written but I still run into trouble.

Jrockit out of memory error

We are getting out of memory error with jrockit1.4.2_08. We used memory debugger tools to find the leak. Apparently there do not seem to be a leak from application perspective. Here is the core dump. Please help me resolve this.
===== BEGIN DUMP =============================================================
JRockit dump produced after 0 days, 05:37:55 on Thu Jun 5 20:39:11 2008
Additional information is available in:
/opt/obs/obs_app/obs31.0/user_projects/admin/jrockit.17430.dump
No core file will be created because core dumps have been
disabled. To enable core dumping, try "ulimit -c unlimited"
before starting JRockit again.
If you see this dump, please open a support case with BEA and
supply as much information as you can on your system setup and
the program you were running. You can also search for solutions
to your problem at http://forums.bea.com in
the forum jrockit.developer.interest.general.
Error code: 52
Error Message: Null pointer exception in native code
Signal info : si_signo=11, si_code=2
Version : BEA WebLogic JRockit(TM) 1.4.2_08 JVM R24.5.0-61 ari-49095-20050826-1856-linux-ia32
Threads / GC : Native Threads, GC strategy: parallel
: mmHeap->data = 0x40416000, mmHeap->top = 0x7ec16000
: mmStartCompaction = 0x45236000, mmEndCompaction = 0x4a056000
CPU : Intel Pentium 4 (HT)
Number CPUs : 4
Tot Phys Mem : 4021997568
OS version : Red Hat Enterprise Linux ES release 2.1 (Panama)
Linux version 2.4.9-e.72smp ([email protected]) (gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-129.7.2)) #1 SMP Tue Jul 3 22:04:51 EDT 2007
State : JVM is running
Command Line : -Djava.class.path=<my own jars list>
java.library.path=/opt/obs/wls/jrockit-j2sdk1.4.2_08/jre/lib/i386/jrockit:/opt/obs/wls/jrockit-j2sdk1.4.2_08/jre/lib/i386:/opt/obs/wls/jrockit-j2sdk1.4.2_08/jre/../lib/i386:/opt/mqm/java/lib:/opt/tib/rv7.1.2/lib:/opt/obs/obs_app/obs31.0/thirdparty:/opt/obs/wls/wls8.1sp3/weblogic81/server/lib/linux/i686:/opt/obs/wls/wls8.1sp3/weblogic81/server/lib/linux/i686/oci920_8
C Heap : Good; no memory allocations have failed
Registers (from context struct at 0x8d5b724/0x8d5b80c):
EAX = 000005f4 EBX = 0000007f
ECX = 7ff8bd90 EDX = 24a18f94
ESI = 7ff46af0 EDI = 00000100
ESP = 7f262bc0 EIP = 4026d58f
EBP = 7f262bd8 EFL = 00010203
CS = 0023 DS = 002b ES = 002b
SS = 002b FS = 00df GS = 00df
Stack:
7f262bc0 :00000000 7ff46af0 00000f94 00000000 00028000 00000000
7f262bd8 :7f262c08 401ffcae 7ff8bd90 24a18f94 00028000 a0000000
7f262bf0 :0a5f1800 7f262c74 08d137a0 00000050 00000000 7f262c34
7f262c08 :7f262c48 4028a7fb 24a18f94 00000000 08d137a0 08d139e4
7f262c20 :581a664c 00000003 08d137a0 00000001 7f262c74 00000000
7f262c38 :7f262ca8 402c28bd 7f262c74 20040144 7f262ca8 402c292f
7f262c50 :7f262c74 00000000 00000000 7f262c84 581a6640 08d137a0
7f262c68 :08d1382c 414d2db8 210d41e8 0a5f1800 08d137a0 7f262d9c
7f262c80 :24a18f95 00000002 00000000 7f262cf8 08d1382c 581a6640
7f262c98 :00000000 00000000 00000000 00000000 7f262ce8 402e0861
7f262cb0 :08d137a0 581a6640 00000020 7f262cf8 210cc499 00000001
7f262cc8 :00000000 7f262ce4 08d139e8 7f262cf0 581a66c0 53b8d780
7f262ce0 :00000000 00000020 08d137a0 210cc43e 08d1382c 08d139e4
7f262cf8 :08116840 08d139e4 00000000 581a6400 210b41ff 00000001
7f262d10 :581a6618 581a6560 210cc499 581a6565 581a6618 581a6560
7f262d28 :210d2744 581a62f0 581a6560 210d2725 2112a995 2112a985
7f262d40 :2112a975 23a67584 581a6578 00000001 00000001 220e35a9
7f262d58 :23a53381 581a62f0 00000000 00000000 581a6548 00000046
7f262d70 :00000000 00000002 00000000 581a62f0 00000001 00000000
7f262d88 :00000000 00000000 581a6530 581a62f0 23a56e15 24a18f95
7f262da0 :24a18ba3 00000000 581a6130 210bead9 581a6038 581a6038
7f262db8 :581a6038 53b88f50 40fa9ca8 581a6308 55b54b00 40fa9c38
7f262dd0 :80000000 55a06030 581a6020 581a6038 581a6020 24a189bb
7f262de8 :40fa9c38 581a6020 40fa9ca8 581a60c0 55a06030 53942ff8
7f262e00 :55b54b00 40fa9ca8 40fa9c38 08d137a0 7f262e24 210b34d8
7f262e18 :40fa9c38 40fa9c68 40fa9ca8 24a18800 402e3a4d 7f262fb3
7f262e30 :0000002c 00000003 7f262ec4 08d1382c 24b196e0 249c4f84
7f262e48 :581a5390 00000000 00000058 7f262e84 402b861a 249c4f84
7f262e60 :7f262e80 08d1382c 00000001 00000001 00000008 00000013
7f262e78 :00000005 581a5fd8 08d139dc 7f262e18 00000003 00000005
7f262e90 :00000005 00000000 00000000 55a06030 55b54b00 7f262e24
7f262ea8 :7f262e24 08d137a0 7f262ee0 24a18800 210b34a0 0000002c
7f262ec0 :7f262fb3 7f262f04 402c8931 08d1382c 1aea85c0 24b196e0
7f262ed8 :00000000 7f262f5c 402c8b74 7f262f54 401aaab0 00000000
7f262ef0 :7f262f5c 7f262f54 401aaab0 401aa6a0 1aea85c0 7f262f64
7f262f08 :402c8c41 08d1382c 249c4f84 00000000 7f262f5c 402c8b74
7f262f20 :00000000 7f262f54 08d13dd0 08d1382c 7f262f9c 00000000
7f262f38 :00000000 7f262f7c 402f2b2d 08d137a0 00000001 7f262f7c
7f262f50 :402f2b24 08d13dd0 402f2b24 7f262fd4 08d1382c 7f262f94
7f262f68 :402dbd4c 08d1382c 08d139dc 249c4f84 7f262fd4 08d139e4
7f262f80 :581a5ee0 00000000 476bd4c0 210b67f6 00000000 08d137a0
7f262f98 :210e7b1b 08d1382c 08d139e0 249c4f84 08d139dc 7f262fd4
7f262fb0 :083e6898 08d139dc 00000000 210eb30d 40fa9ca8 210eb184
7f262fc8 :405bff10 00000005 210e7c48 581a5fb8 581a5fb8 581a5fe0
7f262fe0 :00000000 00000000 581a5690 210e7253 581a5fb8 00000009
7f262ff8 :73a44aa8 73a44aa8 00000005 581a5fb8 00000009 581a5690
7f263010 :246e7cd0 581a5fb8 581a53e8 581a5f48 40fa9b90 40fa9be8
7f263028 :55a06030 55b54b00 40fa9be8 40fa9bd0 246e7b13 55b54b00
7f263040 :55a06030 40fa9b60 55b54b00 55a06030 581a5378 246e79b6
7f263058 :55a06030 55b54b00 57712968 405c6858 40fa9b40 00000001
7f263070 :40fa9b40 2426bab4 55a06030 57712968 57712928 57712968
7f263088 :55b54b00 55b54b00 4b345448 2426ba1b 2426b717 53b88f50
7f2630a0 :405c6858 5393c038 53b88f50 00000002 53b88f40 24266f1f
7f2630b8 :53b88f50 53b88f50 53b88f40 5393c038 53b849c0 00000000
7f2630d0 :53912b90 5393acd0 5393c038 53912b90 242613c8 5393c038
7f2630e8 :00000000 5393acd0 00000000 5393aa60 5393c038 24658a31
7f263100 :5393acd0 4a0dbf40 00000000 4a0dbf40 539125c0 23a74a88
7f263118 :539126e8 00000001 6553be00 539125c0 246587dc 53ebb610
7f263130 :4a0dbf40 00000000 4a124210 00000000 00000000 5393aa60
7f263148 :218aff64 09ccec00 221aa582 5393a440 4a1507e8 4a1507e8
7f263160 :536f07d8 533cdee0 5393a440 533cdee0 000378b6 536f07d8
7f263178 :5393a430 00000004 210b48f0 00000050 0000000f 211080dd
7f263190 :40576ec8 21108145 5393a480 5393aa60 5393aa60 21108074
7f2631a8 :00000003 536f07d8 4a124210 7d1c9048 5393a430 654d5040
7f2631c0 :4a090428 232a5328 7d1c9048 4a124210 229f2aeb 7d1c9048
7f2631d8 :4a124210 4a127090 538f80a8 654d5040 536f07d8 4a127090
7f2631f0 :536f07d8 242438f0 536f07d8 7d1c9048 7d1c9048 538f80a8
7f263208 :5393a418 7d1c9048 229f2a12 536f07d8 7d1c9048 22147208
7f263220 :40528fa8 4056b138 00000000 00000000 405d4858 7d1c9048
7f263238 :2214718a 5393a418 7d1c9048 229f239d 5393a418 536f07d8
7f263250 :7d1c9048 4056b138 41356f20 00000000 536f07d8 40528fa8
7f263268 :4a127090 7d1c9048 5393a418 538f80a8 42562b68 538f81e0
7f263280 :229f2230 219161d1 41356f20 218e2089 42562b6d 41356f20
7f263298 :7f2632b4 210b8c73 402e37ef 7f2633e8 08d137a0 7f2632b4
7f2632b0 :210b3478 210b8c60 402e3a4d ffffffff 00000010 00000000
7f2632c8 :7f263354 08d1382c 200920e0 200282cc 00000000 00000000
7f2632e0 :00000000 7f263314 402b861a 200282cc 7f263310 08d1382c
7f2632f8 :00000001 00000001 00000006 00000006 00000001 08d137a0
7f263310 :00000000 7f2632b4 00000000 00000001 00000001 00000000
7f263328 :00000000 00000000 42562b68 7f2632b4 7f2632b4 08d137a0
7f263340 :00000000 210b8c60 210b3440 00000010 ffffffff 7f263394
7f263358 :402c8931 08d1382c 080d97e0 200920e0 00000000 7f2633e8
7f263370 :402e3550 7f2633cc 00000000 08d1382c 08d1382c 7f263aac
7f263388 :00000000 00000000 080d97e0 7f2633d4 402c9e9f 08d1382c
7f2633a0 :200282cc 00000000 7f2633e8 402e3550 00000001 7f2633cc
7f2633b8 :00000000 00000000 00000000 00000000 00000000 00000000
Code:
4026d48f :83403d9a 008bf4c4 166be850 c4830009 f4c48310 a817e853
4026d4a7 :b70f0009 c0010643 06438966 0ff8c483 048dc0b7 02e0c140
4026d4bf :08438b50 57b7e850 43890003 20c48308 53f4c483 09a87ce8
4026d4d7 :9a38a100 8b64403d 30050300 83403d9a c48310c4 50008bf4
4026d4ef :0915f4e8 084b8b00 4574c985 0f0c558b 8d0443b7 14894004
4026d507 :10558b81 0443b70f c140048d 430302e0 04508908 0f14558b
4026d51f :8d0443b7 e0c14004 08430302 66085089 b80443ff 00000001
4026d537 :b48d09eb 00000026 8bc03100 ec89e85d 768dc35d e5895500
4026d54f :570cec83 458b5356 08558b08 00fc45c7 83000000 b70ff4c4
4026d567 :478d0478 8df8d101 e852ff58 0009a7ed 8310c483 4974fffb
4026d57f :084d8b90 8b5b148d 048d0841 0c558b90 77045039 0850391c
4026d597 :188b0f72 51f4c483 09a7fce8 ebd88900 fc5d892e 768d05eb
4026d5af :8bdf8900 de89fc4d 8939148d 1fe8c1d0 d1101c8d 75f339fb
4026d5c7 :08458bb8 50f4c483 09a7cce8 8dc03100 5e5be865 5dec895f
4026d5df :e58955c3 571cec83 458b5356 fc45c70c 00000000 04788366
4026d5f7 :c7627400 0000f845 558b0000 f8458b0c 8b084203 8b118b08
4026d60f :388b0442 8b08428b 8b028b30 f8c48300 8b04598b 08418b10
4026d627 :5040d829 145d2b52 52575653 10458b53 2c406850 558b4036
4026d63f :bae85208 8bc7ddb3 c4830c55 f8458330 fc45ff0c 0442b70f
4026d657 :7cfc4539 d8658da5 895f5e5b 89c35dec e58955f6 572cec83
4026d66f :38a15356 64403d9a 0503008b 403d9a30 8bf4c483 5ee85000
4026d687 :83000914 c48310c4 e45d8df4 19bbe853 b2e80009 e8000918
Loaded modules:
(* denotes the module causing the exception)
0x08048000-0x0804ce46 /opt/obs/wls/jrockit-j2sdk1.4.2_08/bin/java
0x4001d000-0x40029fab /lib/i686/libpthread.so.0
0x4004e000-0x4006fb42 /lib/i686/libm.so.6
0x40071000-0x4007300c /lib/libdl.so.2
0x40075000-0x401a76e5 /lib/i686/libc.so.6
0x401b2000-0x40388eef* /opt/obs/wls/jrockit-j2sdk1.4.2_08/jre/lib/i386/jrockit/libjvm.so
0x7ec57000-0x7ec66fa5 /opt/obs/wls/jrockit-j2sdk1.4.2_08/jre/lib/i386/libverify.so
0x7ec75000-0x7ec94a0f /opt/obs/wls/jrockit-j2sdk1.4.2_08/jre/lib/i386/libjava.so
0x7ec9c000-0x7ecae3ba /lib/libnsl.so.1
0x7ec97000-0x7ec98705 /opt/obs/wls/wls8.1sp3/weblogic81/server/lib/linux/i686/libweblogicunix1.so
0x7f5f2000-0x7f5f3eff /opt/obs/wls/wls8.1sp3/weblogic81/server/lib/linux/i686/libmuxer.so
0x7f5f6000-0x7f5f95c1 /opt/obs/wls/jrockit-j2sdk1.4.2_08/jre/lib/i386/libioser12.so
0x80318000-0x8031f8bf /opt/obs/obs_app/obs31.0/thirdparty/libXMLC.so
0x80344000-0x8034c66f /opt/tib/rv7.1.2/lib/libtibrvj.so
0x8034e000-0x803563e0 /opt/tib/rv7.1.2/lib/libtibrvcmq.so
0x803d2000-0x803e66bb /opt/tib/rv7.1.2/lib/libtibrvcm.so
0x7fef9000-0x7fefdcaf /opt/tib/rv7.1.2/lib/libtibrvft.so
0x803e8000-0x804341a4 /opt/tib/rv7.1.2/lib/libtibrv.so
Thread Stack Trace:
WARNING: Memory exhausted
at java/lang/Throwable.fillInStackTrace0(Native Method)@0x210cc3f0
at java/lang/Throwable.fillInStackTrace(Unknown Source)@0x210cc499
at java/lang/Throwable.<init>(Unknown Source)@0x210d2744
at java/lang/Exception.<init>(Exception.java:41)@0x210d2725
at java/lang/RuntimeException.<init>(RuntimeException.java:43)@0x2112a995
at java/lang/IllegalArgumentException.<init>(IllegalArgumentException.java:36)@0x2112a985
at java/lang/NumberFormatException.<init>(NumberFormatException.java:38)@0x2112a975
at java/lang/NumberFormatException.forInputString(NumberFormatException.java:48)@0x23a67584
at java/lang/FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1207)@0x220e35a9
at java/lang/Double.parseDouble(Double.java:220)@0x23a56e15

I can't tell from the crash dump what the exact problem is - maybe you are running out of native memory?
You are running a very old JRockit version. Since you are a Oracle/BEA customer, you can get a newer one from BEA Support, or through edelivery.oracle.com.
-- Henrik

Thread Count and Out Of Memory Error

Hi,
I was wondering if setting the ThreadPoolSize to a value which is too low can
cause an out of memory error. My thought is that when it is time for Weblogic
to begin garbage collection, if it does not get a thread fast enough it is possible
that memory would be used up before the garbage collection takes place.
I am asking this because I am trying to track down the cause of an out-of-memory
occurrence, while at the same time I believe I need to raise the ThreadPoolSize.
Thanks,
Mark

Oops ...
I was wondering if setting the ThreadPoolSize to a value which is too
low can cause an out of memory error.No, but the opposite can be true.
My thought is that when it is time for Weblogic
to begin garbage collection, if it does not get a thread fast enough it is
possible that memory would be used up before the garbage collection
takes place.Weblogic doesn't do GC ... that's the JVM and if it needs a thread it will
not be using one of Weblogic's execute threads.
> I am asking this because I am trying to track down the cause of an
out-of-memory occurrenceIt could be configuration (new vs. old heap for example), but it is probably
just data that you are holding on to or native stuff (e.g. type 2 JDBC
driver objects) that you aren't cleaning up correctly.
while at the same time I believe I need to raise the ThreadPoolSize.Wait until you fix the memory issue.
Peace,
Cameron Purdy
Tangosol, Inc.
Clustering Weblogic? You're either using Coherence, or you should be!
Download a Tangosol Coherence eval today at http://www.tangosol.com/
"Mark Glatzer" <[email protected]> wrote in message
news:[email protected]..

Out of memory error in oracle report

when iam running the report its gives me out of memory error can anybody help me

hi
do u have any picture?
generally OutOfMemoryError means, you have to increase the jvm heap size parameters.
sarah

Out of memory error, Urgent!!!

Hi All,
I know there have been a lot of posts for this topic, but none of them seem to address my problem. So please help me out!!! I have written an GUI application that if you open and close for up to certain times, say 10 times, then you will get OOM. I have set the objects to be null when closing the application and called System.gc() as well as System.runFinalization(). Note that I can't call System.exit(0) since this application is not a standalone one. I thought in java if the objects are not used any more, then they will be garbage collected. I may not even have to set the objects to be null. But obviously there are still references to these objects in memory.
I am really frastrated. I read about SoftReference, but I don't get the error while running the application. So I don't think it's very useful for my case.
hhh

>
You probably still have references to the objects
somewhere.
The variables you've set to null, aren't the only
references.
Is there a way that I can find out what referencesare
still alive after I exit the application?
After you exit the application? After you exit
the application, there are zero references, and also
it's impossible to get out of memory errors from java
after it exits.
But I think you may be using the word "application" or
"exit" incorrectly here...
What do you mean you don't get the error whenrunning
the application?I meant I don't get OOM error while running
application. I simply launch the application andthen
exit it. By doing so for about 10 times, then I get
the OOM error. But that's impossible. After the JVM exits, the JVM
can't throw an out of memory error. It can't throw
any errors. It's not running anymore.As I said in my original message, my application is not a standalone one. It is actually one of the tools out of the main application. That's why when I exit this tool I can't use System.exit(0) to stop JVM.

Out of Memory Error - not a RAM issue

I'm using Flash 8 and am getting an out of memory error
simply trying to copy and paste text in Flash. The error tells me
to allocate more memory to flash by getting info on the app in the
finder. This seems strange to me because I thought this was an OS9
function (I'm running OSx 10.4.9). When I get info, there is
actually a twirl down menu for Memory, but everything is grayed out
so I can't change it (it's currently set to 512kb). I don't have
Flash open at the time.
Does anyone know what might be going on?
Thanks ahead of time.
David

The application is downloaded from a server Tomcat and launched by Java Web start.
The settings of the JVM are :
<j2se version="1.6.0.4+" java-vm-args="-Xms20m -Xmx256m -XX:MinHeapFreeRatio=30 -XX:MaxHeapFreeRatio=50" href="http://java.sun.com/products/autodl/j2se" />
So the heap can increase up to 256 Mbytes, which I think is sufficient for the application.
Sometimes the test scenario, which sends the same messages periodically without ending, doesn't cause any problem to the application : the amount of heap it uses remains stable. The application seems to be able to run indefinitely (I let it run for a week without stop).
Sometimes, with the same scenario, after a few runtime hours, the amount of heap used by the application increases suddenly (in a lapse of 2 or 3 minutes). The GC throws an OOM error and the application freezes. The only solution is to re-launch it.
The behavior of the JVM and the GC is beyond understanding to me.
Should I change the tuning parameters of the JVM ?
Would it be a solution to set the Xms and Xmx parameters to the same value, for example 246 MBytes.
Are there other parameters of the JVM that could improve the running of the application ?

Out of memory error in IBM JVM

Similar Messages

Maybe you are looking for