Not enough space

This message was edited 1 time. Last update was at 01/15/2006 08:32:19

Can you suggest me a link which would guide me how to use the rational purify plus tool to detect memory leaks effectively( an online manual type).

I tried using rational purify plus on solaris but the tool gives options to run the native libraries(.c files) individually and not attaching with my application. Testing individually is a huge overhead.
So i am not able to test the native part .
Help required.

This message was edited 1 time. Last update was at 02/09/2006 08:38:38

I ran my application on another memory leak detect tool called GlancePlus but no leaks are detected.
I have some additional info. down here can you help me

Our application uses JNI calls. It works well on windows but is failing on Solaris. The Native code is third party software. I cannot suspect a memory leak as it is working well on windows. I suspect the integration of Java Native code. I have seen that temporary files are created and deleted in /tmp folder. The physical RAM is v.low when observed after this error. I think that solaris is able to use physical RAM but is failing to release memory back.

Stack trace:
-----------------
java.io.IOException: Not enough space
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.<init>(Unknown Source)
at java.lang.Runtime.execInternal(Native Method)
at java.lang.Runtime.exec(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
at JobPreproc.exec(JobPreproc.java)
at JobPreproc.execPreproc(JobPreproc.java)
at JobPreproc.startAnotherPreproc(JobPreproc.java)
at JobChangeMed.tryStartPreprocWaitJob(JobChangeMed.java)
at JobObs.procJobExternalProcCompleted(JobObs.java)
at JobObs.onEvent(JobObs.java)
at EventMan.sendEventToObserver(Unknown Source)
at EventMan.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

The following are the reading taken before submitting the input to my application and after the error is seen.

Before

Physical Memory Used: 597,056 Kb
Physical Memory Free: 1,500,096 kb
Total Physical Memory: 2 GB
Active Processes: 80
Swap Used: 848,290 kb
Swap Free: 3,927,152 kb
Total Swap Space: 3 GB
Virtual Memory Used: 17%

After

Physical Memory Used: 2,048,529 Kb
Physical Memory Free: 48,624 kb
Total Physical Memory: 2 GB
Active Processes: 87
Swap Used: 2,512,696
Swap Free: 2,191,928 kb
Total Swap Space: 3 GB
Virtual Memory Used: 53%

Its an Ultra Sparc IIIi single processor machine and OS is Solaris 10.
Help me out?

This message was edited 1 time. Last update was at 02/09/2006 09:36:39

I cannot suspect a memory leak as it is working well on windows.

java.io.IOException: Not enough space
at java.lang.UNIXProcess.forkAndExec(Native Method)

I'm sorry, but I'm going to say it is your third party library. Why are they java.lang.Runtime.exec()'ing a process? Under Unix this can be an extremely expensive operation. The entire process space is duplicated during a fork()! That means if you have a process taking 2.5GB of space you now need 5GB of space as there will be two of the exact same processes for a small amount of time - until the O/S level exec() can run.

We need more information - what is the processing exec()'ing? Why can't it spawn a thread? Is it possible to change the architecture of this - perhaps a small "spawning" process that can be sent a signal somehow to start the process?

You posted this in the J2EE forum which makes me think you're running this under some sort of application server. Is this the case? I would really caution you to not try to exec() something out of an app server - they are large and it is expensive to do under Unix.

Let us know.

what is the processing exec()'ing?
It uses a third party kit to determine whether the document is color or not.

Why can't it spawn a thread? Is it possible to change the architecture of this - perhaps a small "spawning" process that can be sent a signal somehow to start the process?
Changing the architecture is not possible.

The application uses Tomcat server.

I reverted back to the old library version of the native code and it worked fine.
One observation made was the older library was maintaining some 20K files in the /tmp folder. The total size of the /tmp folder was around 50MB all the time. With the new native library the /tmp folder only a couple of files were created and deleted in few seconds.
Can anything be infered from this observation.

Before I doubted my third party library i did a small test.
I wrote a prog. which creates a files writes some data into it and deletes the file in /tmp folder.I ran the prog. in a loop for 1 hr.
When i compared the memory statistics before and after the run I found that Solaris had consumed around 50MB space and not released back as the files created were deleted.The physical and vitual memory spaces were consumed and not released.
I am doubting that the Solaris is not able to release the memory?
Any solution...

Atlast we could drill down the problem to the third party libraries.
Thanks a lot for your valuable suggestions all the way.

That is fantastic! Glad you got it working.

Can you please share the solution for this problem.I am facing the same. Using Tomcat5.5 and jsp. Running parallel perl scripts from Java using invoking using Runtime.exec(path to perlscript)