Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8050803

misuse of _FORTIFY_SOURCE

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: infrastructure
    • Labels:
      None
    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      Description

      https://bugs.openjdk.java.net/browse/JDK-8032045 suggests turning on
      _FORTIFY_SOURCE to enable additional compiler and runtime bounds
      checks and the like. This is presently only being done in debug (fast
      and slow). Unfortunately, that's a problem.

      _FORTIFY_SOURCE is documented to only do anything useful when
      optimization level is >= 1. See "man feature_test_macros" or here:
      https://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html

      slowdebug doesn't provide that level of optimization, so
      _FORTIFY_SOURCE is at best useless for slowdebug builds.

      And in fact, it is worse than useless, and is actually broken when
      using a recent version of glibc (starting with glibc-2.16?, definitely
      a problem with in 2.18), which now tests the optimization level when
      _FORTIFY_SOURCE is defined and produces a #warning if the optimization
      level is insufficient. [Presumably this is to prevent the user's
      request for additional checking from being silently ignored.] The
      code for this check and warning is in /usr/include/features.h. This
      warning, combined with -Werror being on in at least some places,
      results in a build failure on affected platforms when building
      hotspot.

      I also got a similar build failure for a fastdebug build.

      I further note that slowdebug is now setting _FORTIFY_SOURCE=2. The
      documentation for that says "more checking is added, but some
      conforming programs might fail." That does not seem to me to be an
      desirable behavior to request for most debugging situations; spending
      time first diagnosing some bogus fortify failure and figuring out how
      to turn that feature off is not going to be much fun. It might be
      worth providing as an additional configuration option that a developer
      could use in a specific situation, but not as a default.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              mduigou Mike Duigou
              Reporter:
              kbarrett Kim Barrett
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: