JDK-4790496 : javac fails with error "Alarm Clock" in chroot environment
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.1_02
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_9
  • CPU: generic
  • Submitted: 2002-12-09
  • Updated: 2004-08-06
  • Resolved: 2004-08-06
Related Reports
Relates :  
Description
###@###.### 2002-12-09
javac fails with the following error when compiling under chroot enviroment:

$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac hello.java 
Alarm Clock
$ uname -a
SunOS cpr-bld 5.8 (on28_108528-10 chroot) sun4u sparc SUNW,Ultra-Enterprise

Note1:

same command works well in a non chroot environment:

$ uname -a
SunOS cpr-bld 5.9 on81-raf:02/17/02 sun4u sparc SUNW,Ultra-Enterprise
$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac hello.java
$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/java hello     
main, starting ...
hello !!
$ 


Note2: this problem does happen often, but not always.

Note3: might be related to NFS ? the problem *seems* to happen when javac is taken from a NFS location, not when javac is taken from local file system

Note4: might be related to chroot ? I only saw this problem under chroot environment.

###@###.### 2003-01-09
I'm copying Fred Oliver's email sent to me on Dec. 13th 2002 for information:
Ken,

I've tried running javac from an NFS mount point.  I've still not
been able to reproduce the problem.  (Solaris 8)

Note that I am giving mount commands by hand, rather than depending
on the automounter:

# mount -F nfs american:/export/dist /files1/root/mnt
# chroot /files1/root /mnt/share/java,v1.3.1_02/5.x-sun4/bin/javac Hello.java

Can you test that?

------

Are you seeing the errors when the chroot'd environment is the same 
version of Solaris as the kernel runs?  Please test that specifically.

This is important, because, as mentioned on the web page you referred
to, the kernel and certain user code are tightly coupled.  libthread
is specifically mentioned on that page, and the JVM is very tightly
coupled to libthread.  (You don't want to know how many bugs in 
libthread became visible in java.)

There are other areas where version skew might cause problems, 
including NFS (interfaces between kernel I/O and NFS daemons).

The JVM tests the kernel for features directly, rather than using
uname().  For example, it uses mmap and memcntl to check for Solaris 9
MPSS large page support.  I don't expect that using MPSS (because the
kernel is Solaris 9) in a Solaris 8 chroot environment should cause
a problem.

Fred

To follow-up on Fred Oliver's request for further information, I have
performed some more tests, which I summarize below.

There seem to be some NECESSARY conditions to reproduce this problem
(ie we can never repdroduce the problem without them all):
 1. use of javac using an NFS path (/usr/dist/share/java...) on another host
 2. use of a chroot command that resets / to a Solaris 8 root
 3. use of javac v1.3.1_02 (/usr/dist/share/java,v1.4.0... does not fail)

Some case tests are described below:
Frequency	Context
sometimes	skull.france, using chroot ref28 (s28s_u7wos_08a build).
often (70%)	in Dec. 2002
rarely (10%)	on Jan. 9 2003 (seemed to occur more frequently with -verbose)
often (70%)	cpr-bld.uk using chroot on28 (s28s_u4wos_08 build)

never		skull.france using chroot ref29 (s9_58shwpl3 build)
never		cpr-bld.uk using chroot on81 (s9_54 build)
never		when not using chroot
never		when using a local host version of javac

Note the problem does not occur under a chroot S9 when the host is running S9.
On cpr-bld.uk, I also made some calls with the -verbose option, which may
indicate when the Alarm Clock error occurs:
/usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac hello.java
bash-2.03$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac -verbose hello.java
[parsing started hello.java]
Alarm Clock
bash-2.03$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac -verbose hello.java
[parsing started hello.java]
[parsing completed 198ms]
Alarm Clock
bash-2.03$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac -verbose hello.java
[parsing started hello.java]
[parsing completed 201ms]
Alarm Clock

FINAL NOTE: Note that I don't test the mount manually as Fred describes.
Fred does the chrooting to an NFS root, whereas
I'm chrooting to a directory on the host, then calling /usr/dist/.../javac
from within the created shell. The chroot environment is setup as follows:

        exec /usr/sbin/chroot /share/chroot/$subdir                 /usr/bin/su - ${LOGNAME}${CFLAG:+ -c "${CFLAG}"}

where /share/chroot/on28 is for example the S8 build directory.

Comments
EVALUATION ###@###.### 2002-12-11 I cannot reproduce the problem with 1.3.1_02 or 1.4.2 on Solaris 8 or Solaris 9. Please provide more details, such as the construction of the fake root. In particular, please eliminate NFS as the source of the problem by making all files local. ###@###.### 2003-02-19 Requested information provided Jan. 9th 2003. Removing incomplete state. Ready to provide dbx or other tracing assistance or remote login if needed. ###@###.### 2004-01-05 As requested by Fred early Dec. 2004, I've tried using jdk/1.5.0/beta/b08. This successfully worked 10 times with the -verbose flag and 10 times without. From a quick look, I'm not sure this is a duplicate of 4861802, which is fixed in version 1.4.1_05 1.4.2_02 according to bugtraq. Because, remember from the description section that 1.4.0 also worked fine /usr/dist/share/java,v1.4.0/bin/javac hello.java So, something changed between 1.4.0 and 1.3.1_02 makes a difference. In our chroot build environment, the chrooted /proc is mounted using type proc to the /proc of the real operating system, as shown by this extract: /proc -fstype=proc /proc ###@###.### 2004-08-06 This problem can no longer be reproduced. I'm closing the bug.
06-08-2004