]> git.donarmstrong.com Git - lilypond.git/commit
Issue 4814: grob.cc segfaults with gcc6
authorGuido Aulisi <guido.aulisi@gmail.com>
Fri, 22 Jul 2016 13:26:29 +0000 (15:26 +0200)
committerDavid Kastrup <dak@gnu.org>
Sat, 23 Jul 2016 12:45:27 +0000 (14:45 +0200)
commitb0dce76daf27721ba157cd2ac5d7662d4c8d75f8
tree0a55133262bd8c2642454f752092e05e9f786ea7
parentb680788cd1c671d52819d69e9e130ff45361a590
Issue 4814: grob.cc segfaults with gcc6

From the release notes of GCC 6:

    Optimizations remove null pointer checks for this

    When optimizing, GCC now assumes the this pointer can never be null,
    which is guaranteed by the language rules. Invalid programs which
    assume it is OK to invoke a member function through a null
    pointer (possibly relying on checks like this != NULL) may crash or
    otherwise fail at run time if null pointer checks are optimized
    away. With the -Wnull-dereference option the compiler tries to warn
    when it detects such invalid code.

    If the program cannot be fixed to remove the undefined behavior then
    the option -fno-delete-null-pointer-checks can be used to disable
    this optimization. That option also disables other optimizations
    involving pointers, not only those involving this.

As a consequence, we cannot call a member function on a prospective null
pointer (which actually is a bad idea for a number of other reasons,
like when anything tries accessing the vtable) and then try sorting out
the condition in the routine itself.

This problem was first observed with Fedora 24.  The Ubuntu GCC6
prerelease does not show this problem; presumably the respective
optimization has been disabled in the Ubuntu/Debian packaging because of
affecting other programs.

Commit-message-by: David Kastrup <dak@gnu.org>
Signed-off-by: David Kastrup <dak@gnu.org>
lily/grob.cc