SUGGESTED FIX

See attached 7168520-webrev-cr0.tgz for the proposed fix.
                                     

EVALUATION

The work around to make aurora happy is to create a libjsig.diz
file in the client and server VM directories that contains the
libjsig.debuginfo symlink.
                                     

EVALUATION

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce165aa48dcb
                                     

EVALUATION

http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/a9cf66e39b38
                                     

EVALUATION

The following hotspot repo changeset is what added the
ZIP_DEBUGINFO_FILES feature:

Changeset: d652a62d6e03
Author:    dcubed
Date:      2012-03-23 11:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d652a62d6e03

7102323: RFE: enable Full Debug Symbols Phase 1 on Solaris
Summary: Add support for ENABLE_FULL_DEBUG_SYMBOLS and ZIP_DEBUGINFO_FILES build flags. Add support for .diz files.
Reviewed-by: dholmes, ohair, sspitsyn


The above changeset is what causes the

    jre/lib/<arch>/libjsig.debuginfo

files to be ZIPed into:

    jre/lib/<arch>/libjsig.diz

files in order to reduce on-disk footprint.

The following symbolic links:

    jre/lib/<arch>/client/libjsig.debuginfo
    jre/lib/<arch>/server/libjsig.debuginfo

were added by the following jdk repo changeset:

Changeset: 029ba13aa0df
Author:    dcubed
Date:      2011-09-20 19:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/029ba13aa0df

7085944: 3/3 FDS: gdb does not find debug symbols for libjsig link
Summary: Add support for importing .debuginfo files from HSX.
Reviewed-by: phh

! make/common/Defs-linux.gmk
! make/common/Defs-solaris.gmk
! make/java/redist/Makefile
! make/java/redist/sajdi/Makefile

In particular, the symlinks are created by the
make/java/redist/Makefile.
                                     

EVALUATION

Here are what I found:

1. libjsig.debuginfo is added on 5/11 because when I look at the past few nightly builds, that was the first time it showed up.
Someone added a symlink libjsig.debuginfo, but the actual file it links to does not exist.

2. Then I check the hg log. Lana did an integration on 5/11. Then olagneau did a push after the merge.
I have cc  Olivier and Lana in this email.

changeset:   5367:f131d4361faf
user:        olagneau
date:        Fri May 11 14:13:29 2012 -0700
summary:     7144861: speed up RMI activation tests

I have sent an email to Olivier and Lana.
                                     

EVALUATION

A bit of historical background:

The <arch>/client/libjsig.debuginfo and <arch>/server/libjsig.debuginfo
symlinks are created by the 'jdk' repo. Just like the <arch>/client/libjsig.so
and <arch>/server/libjsig.so symlinks are created by the 'jdk' repo.

The <arch>/libjsig.debuginfo file is created by the 'hotspot' repo just like
the <arch>/libjsig.so file is created by the 'hotspot' repo. However, debug
info files are now ZIP'ed by default to save disk space so a default hotspot
build will create <arch>/libjsig.diz instead of <arch>/libjsig.debuginfo.

When we added the ZIP_DEBUGINFO_FILES feature, we left the libjsig.debuginfo
symlinks alone since a symlink can't really be compressed any further. During
all of our pre-integration testing, we never saw a failure due to the "dangling"
symlink and I'm very surprised to see this one.

It looks like some hudson tool or another is trying to read what the symlink
refers to instead of processing symlinks as they are. That's a little
worrisome in that I wonder if this tool is also making a copy of the file
to which the symbolic link refers instead of copying the symlink itself.
With FDS that could result in multiple copies of some very large files...


And an e-mail reply to Lana:

> Thank you for the explanation. However I think that Christine was saying the link is broken.
>
> $ ls -l libjsig.debuginfo
> lrwxrwxrwx 1 nobody java_re 20 2012-05-13 18:03 libjsig.debuginfo -> ../libjsig.debuginfo
>
> $ ls -l ../libjsig.debuginfo
> ls: cannot access ../libjsig.debuginfo: No such file or directory

Yes, the link is "broken" or "dangling" and that is intentional.
Whatever is being used to copy this tree is missing the "don't
follow symlinks" option. The '-y' option for zip... I think...
                                     

EVALUATION

Yes, use -y for zip, or avoid zip and use tar.
                                     

EVALUATION

I pushed the changeset mentioned in #1 above:

changeset:   5367:f131d4361faf
user:        olagneau
date:        Fri May 11 14:13:29 2012 -0700
summary:     7144861: speed up RMI activation tests

This changes files the JDK repo only in the test/java/rmi and test/sun/rmi directories. I'm pretty certain this has nothing to do with libjsig.debuginfo.
                                     

EVALUATION

Aurora is failing to zip this directory tree, because of this unresolvable symlink. 

Please note that Aurora is using jdk6 (regular FileIO) to walk through the tree and read as input stream and zipped it before transfering content from Hudson servers to specific host machine.

/net/aurora-ds.us.oracle.com/data/export/aurora/sca/rehudson/n/mustang/hudsonjobs/jdk8_tl-1-prebuild/workspace/ws-b39-2012-05-13_231/build/linux-i586/j2sdk-image/jre/lib/i386/client

As you see in above entry, we have several symlinks to follow to reach THE content. Currently, we (jdk6) don't have feature to selectively follow links or not. 

(NOTE: we are not using standard zip utility). 

>>When we added the ZIP_DEBUGINFO_FILES feature, we left the libjsig.debuginfo
>>symlinks alone since a symlink can't really be compressed any further. During
>>all of our pre-integration testing, we never saw a failure due to the "dangling"
>>symlink and I'm very surprised to see this one.

We can handle zipped file, as it hides such unresolvable symlink from us. 
It would help us, if you can include these files as part of your ZIP_DEBUGINFO_FILES.