[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: #4814 grob

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.

Ugh. Another one of those "undefined behavior means that we can screw the user by throwing out code written intentionally without warning" things. So something like assert(this); will become a nop, causing much harder to debug crashes later on. I thought that one developer particularly known for this hobby had moved to new pastures mostly.

At any rate, this might explain why I still fail to see the crash with GCC6 on Ubuntu; it's an option likely to get overruled with local patches from people trying to keep a distribution running.

Hm. Does the unmodified source work after

./configure CXX="g++ -fno-delete-null-pointer-checks"
make clean
make

? The description is not completely suggestive of that optimization:

'-fdelete-null-pointer-checks'
Assume that programs cannot safely dereference null pointers, and
that no code or data element resides at address zero. This option
enables simple constant folding optimizations at all optimization
levels. In addition, other optimization passes in GCC use this
flag to control global dataflow analyses that eliminate useless
checks for null pointers; these assume that a memory access to
address zero always results in a trap, so that if a pointer is
checked after it has already been dereferenced, it cannot be null.

Note however that in some environments this assumption is not true.
Use '-fno-delete-null-pointer-checks' to disable this optimization
for programs that depend on that behavior.

This option is enabled by default on most targets. On Nios II ELF,
it defaults to off. On AVR and CR16, this option is completely
disabled.

Passes that use the dataflow information are enabled independently
at different optimization levels.

[issues:#4814] grob.cc segfaults on Fedora 24 with gcc6

Status: Accepted
Created: Sat Mar 26, 2016 09:51 PM UTC by Valentin Villenave
Last Updated: Fri Jul 22, 2016 01:44 PM UTC
Owner: nobody

Greetings,
I’m trying to run LilyPond on Fedora 24 (with GCC 6.0); I’m able to compile it (with and without guile2 enabled) but when trying to use it, many LilyPond files trigger a segfault:

Parsing...
Interpreting music...
Preprocessing graphical objects...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000496c2f in Grob::get_offset (address@hidden,
address@hidden) at grob.cc:400
400       if (dim_cache_[a].offset_)

Here are the regtests that reproduce the bug (the others compile just fine):

beam-cross-staff-slope.ly
dynamics-alignment-breaker-linebreak.ly
dynamics-alignment-breaker.ly
dynamics-alignment-breaker-order.ly
dynamics-alignment-breaker-subsequent-spanner.ly
dynamics-alignment-no-line-linebreak.ly
dynamics-alignment-no-line.ly
dynamics-context-textspan.ly
dynamics-unbound-hairpin.ly
event-listener-output.ly
fermata-rest-position.ly
font-name.ly
full-measure-rest-fermata.ly
line-arrows.ly
line-style-zigzag-spacing.ly
make-relative.ly
markup-line-thickness.ly
markup-note-grob-style.ly
metronome-mark-broken-bound.ly
minimum-length-after-break.ly
mm-rests2.ly
morgenlied.ly
mozart-hrn-3.ly
multi-measure-rest-center.ly
multi-measure-rest.ly
multi-measure-rest-spacing.ly
multi-measure-rest-text.ly
music-function-end-spanners.ly
offsets.ly
page-turn-page-breaking-repeats.ly
part-combine-a2.ly
part-combine-mmrest-apart.ly
part-combine-mmrest-shared.ly
part-combine-silence-mixed.ly
property-nested-override.ly
quote-cue-during.ly
quote-cue-event-types.ly
repeat-percent-count.ly
repeat-percent-count-visibility.ly
repeat-percent.ly
rest-positioning.ly
scheme-text-spanner.ly
skiptypesetting-multimeasurerest.ly
slur-broken-trend.ly
slur-scoring.ly
slur-tie-control-points.ly
slur-vertical-skylines.ly
spanner-after-line-breaking.ly
staff-mixed-size.ly
stem-direction.ly
stencil-scale.ly
tablature-full-notation.ly
tablature-harmonic-functions.ly
tablature-tie-spanner.ly
text-spanner-attachment-alignment.ly
text-spanner-full-rest.ly
text-spanner-override-order.ly
tie-direction-manual.ly
tie-pitched-trill.ly
trill-spanner-auto-stop.ly
trill-spanner-broken.ly
trill-spanner-chained.ly
trill-spanner-grace.ly
trill-spanner.ly
trill-spanner-pitched-consecutive.ly
trill-spanner-pitched-forced.ly
trill-spanner-pitched.ly
trill-spanner-scaled.ly

What makes is weird is that the bug happens both with my LilyPond
build (latest master branch) and with my distribution’s package
(Fedora repos generally have the latest development release: as of now
it’s 2.19.38 but this also happened with .37 and .36); however, GUB
packages of the exact same development release, don’t reproduce the
segfault.

Could it be because Fedora 24 is using GCC6? I’ve tried bisecting but I’m unable to compile any version older than a couple of weeks, prior to David’s more rigorous smob types:
http://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=c6758d6d12e33779fc81218693d5650682d8a1ca

Let me know if I can provide any other information (and feel free to close this issue if it turns out to be caused by something in my environment).

Sent from sourceforge.net because address@hidden is subscribed to https://sourceforge.net/p/testlilyissues/issues/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

From:	Auto mailings of changes to Lily Issues
Subject:	[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: #4814 grob.cc segfaults on Fedora 24 with gcc6
Date:	Fri, 22 Jul 2016 14:57:05 +0000