United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7165060 dtrace tests fail with FDS debug info files
JDK-7165060 : dtrace tests fail with FDS debug info files

Details
Type:
Bug
Submit Date:
2012-04-27
Status:
Resolved
Updated Date:
2013-07-19
Project Name:
JDK
Resolved Date:
2012-05-26
Component:
hotspot
OS:
solaris
Sub-Component:
build
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs24
Fixed Versions:
hs24 (b12)

Related Reports
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
The desired defaults for Full Debug Symbols for HotSpot are:

    FULL_DEBUG_SYMBOLS=1
    ZIP_DEBUGINFO_FILES=1

when configured this way on Solaris SPARC, Solaris SPARC-v9 and
Solaris X64, the VM/NSK dtrace subsuite has hundreds of failures.

The following bug was used to temporarily disable FDS on Solaris:

    7164344 2/3 enabling ZIP_DEBUGINFO_FILES causes unexpected test
                failures on Solaris and Windows
I did a few experiments to characterize the failure mode:

-rwxr-xr-x   1 dcubed   green    557795616 Apr 26 12:03 libjvm.so.no_strip*
-rwxr-xr-x   1 dcubed   green    30931184 Apr 26 14:43 libjvm.so.strip-x*
-rwxr-xr-x   1 dcubed   green    556538156 Apr 26 16:02 libjvm.so.debuglink*
-rwxr-xr-x   1 dcubed   green    29673632 Apr 26 16:23 libjvm.so.strip-debuglink*
-rwxr-xr-x   1 dcubed   green    29656092 Apr 26 16:52 libjvm.so.objcopy-strip-debug*

no_strip
--------

- disable the code that calls gobjcopy so creation of
  the libjvm.debuginfo is skipped
- disable the code that links from libjvm.so
  to libjvm.debuginfo
- disable the 'strip -x' of libjvm.so
- test results were 316 pass and 13 fail (all known)

strip-x
-------

- disable the code that calls gobjcopy so creation of
  the libjvm.debuginfo is skipped
- disable the code that links from libjvm.so
  to libjvm.debuginfo
- keep the 'strip -x' of libjvm.so
- test results were 316 pass and 13 fail (all known)

debuglink
---------

- keep the code that calls gobjcopy so creation of
  the libjvm.debuginfo is done
- keep the code that links from libjvm.so
  to libjvm.debuginfo
- disable the 'strip -x' of libjvm.so
- stopped the test run after 8/10 failures

strip-debuglink
---------------

- keep the code that calls gobjcopy so creation of
  the libjvm.debuginfo is done
- move the 'strip -x' of libjvm.so before the debuglink
- keep the code that links from libjvm.so
  to libjvm.debuginfo
- stopped the test run after 8/10 failures

objcopy-strip-debug
-------------------

- keep the code that calls gobjcopy so creation of
  the libjvm.debuginfo is done
- use 'objcopy --strip-debug' instead of 'strip -x'
- keep the code that links from libjvm.so
  to libjvm.debuginfo
- stopped the test run after 8/10 failures

                                    

Comments
EVALUATION

The VM/NSK dtrace tests don't like the libjvm.so file after the
'gobjcopy --add-gnu-debuglink' has been done. Even if the debug
info is left in libjvm.so (no 'strip -x' and no 'gobjcopy
--strip-debug'), just using 'gobjcopy --add-gnu-debuglink' is
enough to make the VM/NSK dtrace tests fail.

I think this means one of two things:

1) the gobjcopy command is corrupting the libjvm.so file
2) the dtrace subsuite is somehow confused by the debug
   info link that is added to libjvm.so
                                     
2012-04-27
EVALUATION

Keith says the dtrace cmd relies on the SUNW_dof section that is
added during the libjvm build process. Here's what elfdump shows
libjvm.so.no_strip:

elfdump.no_strip:Section Header[18]:  sh_name: .SUNW_dof
elfdump.no_strip:    sh_size:      0x249af         sh_type:    [ SHT_SUNW_dof ]
elfdump.no_strip:    [1222]  0x009edadf 0x00000000  OBJT GLOB  D    0 .SUNW_dof      _etext
elfdump.no_strip:      [19]  0x009c9130 0x00000000  SECT LOCL  D    0 .SUNW_dof      
elfdump.no_strip:  [178887]  0x009c9130 0x000249af  OBJT LOCL  H    0 .SUNW_dof      ___SUNW_dof
elfdump.no_strip:  [298191]  0x009edadf 0x00000000  OBJT GLOB  D    0 .SUNW_dof      _etext


Here's what elfdump shows for libjvm.so.debuglink:

elfdump.debuglink:libjvm.so.debuglink: .symtab: bad symbol entry: ___SUNW_dof: section[18] size: 248: is smaller than symbol size: 149935
elfdump.debuglink:  [178887]  0x009c9130 0x000249af  OBJT LOCL  H    0 .dynamic       ___SUNW_dof

The SUNW_dof section is gone which is probably not a good thing.
                                     
2012-04-30
EVALUATION

Just looking at ELF section header names:

$ elfdump -c libjvm.so.no_strip \
| sed -n 's/^Section Header.*sh_name: //p' | sort > g0

$ elfdump -c libjvm.so.debuglink \
| sed -n 's/^Section Header.*sh_name: //p' | sort > g1

$ diff g?
1,3d0
< .SUNW_cap
< .SUNW_dof
< .annotate
19a17
> .gnu_debuglink
                                     
2012-04-30
EVALUATION

I filed the following Solaris bug for the gobjcopy corruption:

     7165526 2/3 gobjcopy corrupts SUNW_dof section in libjvm.so and
                 breaks dtrace

Work on this bug is blocked until a Solaris 10 patch for gobjcopy
is available.
                                     
2012-05-01
SUGGESTED FIX

See the attached 7165060-webrev-cr0.tgz and
7165060-webrev-cr1.tgz for the proposed work around.
Also re-enables FDS on Solaris and ZIP_DEBUGINFO_FILES
on Windows.
                                     
2012-05-15
EVALUATION

Work around 'gobjcopy --add-gnu-debuglink' failure by adding
a temporary tool that adds the '.gnu_debuglink' section and
nothing more.
                                     
2012-05-15
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7d4e6dabc6bf
                                     
2012-05-15
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7d4e6dabc6bf
                                     
2012-05-23
EVALUATION

http://hg.openjdk.java.net/hsx/hsx23.2/hotspot/rev/7d4e6dabc6bf
                                     
2012-05-30
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7d4e6dabc6bf
                                     
2012-06-29



Hardware and Software, Engineered to Work Together