You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by "Heuman, Robert" <Ro...@gs.com> on 2000/08/29 17:24:35 UTC
Javadoc Hang on Solaris
We are having a problem with ant hanging when it executes a javadoc target
on solaris (we are running on 8 processor 4500). The javadoc process gets 2
seconds of cpu time and then hangs. The javadoc command works fine when run
directly from the shell.
If we kill the hanging javadoc process, ant prints the message:
build.xml:59: Exec returned: 143
I notice that /usr/include/syscall.h declares:
#define SYS_fork1 143
This would imply that the subprocess is hanging on a fork1() command.
The solaris doc says the following about fork1:
If fork1() is called in a Solaris thread program or fork()
is called in a POSIX thread program, and the child does more
than just call exec(), there is a possibility of deadlocking
in the child. To ensure that the application is safe with
respect to this deadlock, it should use pthread_atfork(3T).
Should there be any outstanding mutexes throughout the pro-
cess, the application should call pthread_atfork(3T), to
wait for and acquire those mutexes, prior to calling fork().
(See attributes(5) "MT-Level of Libraries")
Or, maybe this is a red herring.
Has anyone else had problems with hangs?
Re: Javadoc Hang on Solaris
Posted by Ken Wood <kw...@i2.com>.
Well, check this - what VERSION of Solaris and
Java are you running?
JDK 1.2.x and later is NOT supported on Solaris 2.5.1.
You need to be on at least Solaris 2.6 to use JDK 1.2 or
JDK 1.3 javadocs.
"Heuman, Robert" wrote:
>
> We are having a problem with ant hanging when it executes a javadoc target
> on solaris (we are running on 8 processor 4500). The javadoc process gets 2
> seconds of cpu time and then hangs. The javadoc command works fine when run
> directly from the shell.
>
> If we kill the hanging javadoc process, ant prints the message:
>
> build.xml:59: Exec returned: 143
>
> I notice that /usr/include/syscall.h declares:
>
> #define SYS_fork1 143
>
> This would imply that the subprocess is hanging on a fork1() command.
>
> The solaris doc says the following about fork1:
>
> If fork1() is called in a Solaris thread program or fork()
> is called in a POSIX thread program, and the child does more
> than just call exec(), there is a possibility of deadlocking
> in the child. To ensure that the application is safe with
> respect to this deadlock, it should use pthread_atfork(3T).
> Should there be any outstanding mutexes throughout the pro-
> cess, the application should call pthread_atfork(3T), to
> wait for and acquire those mutexes, prior to calling fork().
> (See attributes(5) "MT-Level of Libraries")
>
> Or, maybe this is a red herring.
>
> Has anyone else had problems with hangs?