Cherrypick fix for upstream issue 4814 which fixes segfaults in grob.cc in newer...

diff --git a/debian/changelog b/debian/changelog
index 2b8a6275ae9f104811a7131196c31d46dc6700a4..c3724e616805f6367e999db10f448ab367955c98 100644 (file)
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,9 @@ lilypond (2.18.2-9) unstable; urgency=medium
   * There is no need to remove /usr/share/info/lilypond anymore, as the
     info directory is the master source for the images which are built and
     are linked to from the HTML. (Closes: #871631)
+  * Cherrypick fix for upstream issue 4814 which fixes segfaults in
+    grob.cc in newer versions of GCC (Closes: #866129). Thanks to Antonio
+    Ospite for mentioning the patch.
 
  -- Don Armstrong <don@debian.org>  Tue, 15 Aug 2017 13:38:30 -0700
 

diff --git a/debian/patches/Issue-4814-grob.cc-segfaults-with-gcc6 b/debian/patches/Issue-4814-grob.cc-segfaults-with-gcc6
new file mode 100644 (file)
index 0000000..bb10354
--- /dev/null
+++ b/debian/patches/Issue-4814-grob.cc-segfaults-with-gcc6
@@ -0,0 +1,64 @@
+From b0dce76daf27721ba157cd2ac5d7662d4c8d75f8 Mon Sep 17 00:00:00 2001
+From: Guido Aulisi <guido.aulisi@gmail.com>
+Date: Fri, 22 Jul 2016 15:26:29 +0200
+Subject: [PATCH] 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 | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/lily/grob.cc b/lily/grob.cc
+index 7ce89d5015..eafa66288e 100644
+--- a/lily/grob.cc
++++ b/lily/grob.cc
+@@ -333,7 +333,7 @@ Real
+ Grob::relative_coordinate (Grob const *refp, Axis a) const
+ {
+   /* eaa - hmmm, should we do a programming_error() here? */
+-  if ((this == NULL) || (refp == this))
++  if (refp == this)
+     return 0.0;
+ 
+   /* We catch PARENT_L_ == nil case with this, but we crash if we did
+@@ -342,7 +342,8 @@ Grob::relative_coordinate (Grob const *refp, Axis a) const
+   if (refp == dim_cache_[a].parent_)
+     return off;
+ 
+-  off += dim_cache_[a].parent_->relative_coordinate (refp, a);
++  if (dim_cache_[a].parent_ != NULL)
++    off += dim_cache_[a].parent_->relative_coordinate (refp, a);
+ 
+   return off;
+ }
+-- 
+2.11.0
+

diff --git a/debian/patches/series b/debian/patches/series
index 25f6388f1bce4562e63ccae71a36bdd4e769a3f5..8e4644c22faa0fdc1902cb8ef11809b1f32e96b2 100644 (file)
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -18,3 +18,4 @@ use_debians_help2man
 0012-remove-spurious-declarations-in-c-tokenize.lex.patch
 0100-guile-config-link-static-libguile.a-for-lilypond.patch
 0101-read_relocation_dir-in-lilypond_datadir-too.patch
+Issue-4814-grob.cc-segfaults-with-gcc6