Re: Error code -1073741819 with tie and tenuto

[Bernhard Kleine]

Am 13.11.2016 um 23:16 schrieb David Kastrup:
> Bernhard Kleine <address@hidden> writes:
>
>> Am 13.11.2016 um 22:51 schrieb Simon Albrecht:
>>> On 13.11.2016 22:49, Noeck wrote:
>>>> Both
>>>>
>>>> \relative c {
>>>>    <f ces' es>1~-- |
>>>>    <f ces' des> |
>>>> }
>>>>
>>>> and
>>>>
>>>> \relative {
>>>>    <cis' e>1~-- |
>>>>    <cis d> |
>>>> }
>>>>
>>>> are compiled without problems here (2.19.49, Ubuntu 16.10, 64bit).
>>> OK, so it’s a bug already fixed.
>>>
>>> Best, Simon
>> But withour knowing it!
> I wouldn't say that.  This is
>
> commit 93f3d637efbc038b837cf64fae0872e873e4f039
> Author: David Kastrup <address@hidden>
> Date:   Fri Sep 2 23:11:53 2016 +0200
>
>     Issue 4965: Create and use Grob::parent_relative
>     
>     This function checks for the existence of a Grob parent before
>     calculating a coordinate relative to it.  This should hopefully
>     clean up the most relevant problems caused by issue 4814
>     and the original GCC 6 optimization causing it.
>
> fixed in 2.19.48.
>
>
> Conversely, issue 4814 was addressed in 2.19.46 by
>
> commit b0dce76daf27721ba157cd2ac5d7662d4c8d75f8
> Author: Guido Aulisi <address@hidden>
> Date:   Fri Jul 22 15:26:29 2016 +0200
>
>     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 <address@hidden>
>     Signed-off-by: David Kastrup <address@hidden>
>
>
> and the fix was relying on incomplete analysis, making it responsible
> for the damage reported here.
I am very glad that the reason has been found and I was solely ignorant.
Sorry.
Kind regards and many thanks for a beautiful program.

Bernhard

-- 
spitzhalde9
D-79853 lenzkirch
address@hidden
www.b-kleine.com, www.urseetal.net
-
thunderbird mit enigmail
GPG schlüssel: D5257409
fingerprint:
08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09

signature.asc
Description: OpenPGP digital signature