I have recently had problems launching bugster from my home desktop [running S10 FCS, with "About Java" reporting "Version 1.5.0 (build 1.5.0_01-b08)"]. I launch bugster via a script which essentially turns around and runs "/usr/bin/javaws https://bugster.central.sun.com/bugster.jnlp", but the javaws process just hung. Both pstack(1) and truss(1) indicated that javaws was stuck in accept(3socket), which made me think it was a networking or proxy problem. But once I ran truss from the get-go, I saw:

21058: fork1() Err#12 ENOMEM

As opposed to on my desktop in the office where it worked:

592504: fork1() = 592505
592505: fork1() (returning as child ...) = 592504
592505: getpid() = 592505 [592504]
...

So it appears that javaws is not checking the return value of fork(2) to make sure the system call succeeded, or is not handling the fork() failure appropriately. The lack of proper fork() error handling is the subject of 6235110.

But it turns out the my home machine has 1GB of RAM plus another half a gig of swap, almost all of which was free, so it's a bit odd that 1.4 GB of free memory would not be sufficient, but watching with vmstat(1M), I saw that javaws reserved a full GB *before* attempting to fork(), thus reducing free memory from 1.4 GB to 0.4 GB, and since fork(2) duplicates the address space of the calling process, *another* GB would be needed, but with on 0.4 GB available, ENOMEM was the result. Why on earth javaws needs to reserve a full GB of memory *before* swapping, but that will be the subject of a separate bug. But it explains why my office desktop, which has 3 GB of RAM and another 1.5 GB of swap, does not run into this problem.
###@###.### 2005-03-02 19:59:40 GMT