On 02/04/11 13:06, Bill Shannon wrote:
Bart Smaalders wrote on 02/ 4/11 11:49 AM:
On 02/04/11 11:33, Bill Shannon wrote:
This isn't really specific to OpenSolaris since it also happens on
Solaris 10, but maybe someone here can give me some ideas?
I have a java program that is failing because it does something that
calls
fork1(), which fails with ENOMEM (confirmed using truss):
27010/2: fork1() Err#12 ENOMEM
I've used both the 32-bit and 64-bit versions of the JVM. Using the
64-bit
version, I see the heap expand to just over 4GB before it forks:
27010/30: brk(0x107DE3D90) = 0
I have almost 160 GB of swap space:
$ swap -s
total: 806336k bytes allocated + 167872k reserved = 974208k used,
159746184k available
It doesn't seem like it can possibly be running out of swap space.
What other reasons would cause fork1() to fail with ENOMEM?
_______________________________________________
The vm system is rather fond of using ENOMEM as a generic error bucket.
If you have a way of reproducing the problem, a bit of DTrace will
quickly turn
up the reason. I assume it's only the 32 bit version
that is failing to fork, right?
Sorry, I wasn't clear. The 64-bit version fails as well. With the
32-bit
version I limit the Java heap to 2GB. It doesn't run out of heap, but
the
fork fails.
I'm sure dtrace will solve every problem I have, but I don't know how
to use it to solve this problem! :-( Hints?
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Hi,
Please excuse me for getting into the discussion.
I think in solaris 10 the /tmp file is place by default in swap, if
/tmp is full it may give that error.
I found an article on that theory.
http://nilesh-joshi.blogspot.com/2010/03/tmp-file-system-full-swap-space-limit.html
--
Regards,
Edward
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
