Thomas Morley <thomasmorle...@gmail.com> writes:
>> I can confirm the bug with a build from
>> commit d6e93146b9f25e914373caeced7314237cc53e2f
>> (Don't remember which optimizing-option I used, though)
>>
>> gdb says
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00000000004ae5ab in Grob::get_offset (a=X_AXIS, this=0x0) at
>> /home/hermann/lilypond-git/lily/grob.cc:401
>> 401 if (dim_cache_[a].offset_)
>>
>> complete output from
>> (gdb) bt
>> attached.
>>
>> Cheers,
>> Harm
>
> Being on 64-bit Ubuntu 16.04 with
>
> gcc --version
> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609
Oh. Then it is not a gcc-6 problem after all. This is puzzling. My
gcc is built on 32bit but I tell it to compile to 64bit, and it does
so. And the bug you are seeing _very_ much looks like the one fixed
with
commit b0dce76daf27721ba157cd2ac5d7662d4c8d75f8
Author: Guido Aulisi <guido.aul...@gmail.com>
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 <d...@gnu.org>
Signed-off-by: David Kastrup <d...@gnu.org>
So maybe we have another situation triggering it? Or rather, our GCC-6
fix did not catch all the same situations as the original code before
GCC-6 optimized it away did? This fix was committed in 2.19.46 which
would be consistent with the report.
Why don't I see the problem? Does it depend on the memory layout,
maybe?
At any rate, try a backtrace so that we figure out which function is
responsible for the "this" pointer being 0.
--
David Kastrup
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
