[Bug c/66230] Using optimizations causes program to segfault

[Bug c/66230] Using optimizations causes program to segfault

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-05-21
                 CC|                            |trippels at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Please attache a small self-contained testcase. 
Nobody here has the time to clone and build random projects.

And normally issues like these are caused by invoking undefined behavior.
Try to build the project with -fsanitize=undefined and see what runtime
errors it reports.

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230

--- Comment #2 from gpnuma at centaurean dot com ---
I understand you're short of time but this problem is very difficult to
reproduce !!

I did try to compile and link with -fsanitize=undefined this morning, now
here's the interesting part :
* no warning was generated by ubsan 
* everything works fine
As soon as I remove -fsanitize=undefined, I get the segfault again, so I
suspect the problem happens during the optimization stages.

The fact that if I add a useless line of code like printf("...") at the start
of the called function cancelling the problem makes me wonder if it could be
that the function pointer is not properly "captured" by gcc or that it
"changes" after optimizations.

Here is what I'm doing to be more accurate :
1) I have a set of functions at the top of a file (functionA, functionB, ...)
2) At the bottom of that file I have another function which stores the function
pointers of these functions using &functionA, &functionB etc... in an array.
3) Later on, I access the functions using an index to that array, and with gcc
4.8 / -O3 *only*, this fails and segfaults.

So my thinking is maybe the function pointers are stored correctly, but then
the optimizer "changes" this function's address or the function itself making
the initial pointer wrong which leads to a segfault... just a wild guess.
I think that adding the printf or a void function maybe adds some sort of
"unoptimizable" code at the start (like IO) and therefore the initial stored
pointer is unchanged after optimizations.
Oh yeah, it's worth mentioning that otherwise (if I don't put a bogus printf)
the first line of code of the function is a __builtin_memcpy which is probably
highly optimizable.

I'll try to come up with a short code example if I get the time later on.

Thank you
Guillaume

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230

--- Comment #4 from gpnuma at centaurean dot com ---
Sorry I meant gcc 4.9.2 / -O3 of course, 4.8 works fine.

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230

--- Comment #5 from gpnuma at centaurean dot com ---
Ok I did just try "-fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations" and the issue is still there.

If I add the printf("something"); at the top of the function, everything works
normally.

[Bug c/66230] Using optimizations causes program to segfault

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230

--- Comment #7 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 for a similar bug
in LZ4.

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230

--- Comment #8 from gpnuma at centaurean dot com ---
Thanks Markus I didn't think these alignment issues were actually the problem,
it goes a long way.

By doing memmoves instead of pointer cast allocations I got rid of the
segfault, but of course things are much slower... this "undefined behaviour" is
really treacherous !!

Is there any way to ensure proper alignment so I don't fall into this trap and
still benefit from maximum speed ?

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230

--- Comment #9 from gpnuma at centaurean dot com ---
What I mean is the structs I was using the pointer casts allocations with are
instanciated by the program itself, so there could be a way to instanciate them
with the required alignment I suppose.

[Bug c/66230] Using optimizations causes program to segfault

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230

--- Comment #10 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to gpnuma from comment #8)
> Thanks Markus I didn't think these alignment issues were actually the
> problem, it goes a long way.
> 
> By doing memmoves instead of pointer cast allocations I got rid of the
> segfault, but of course things are much slower... this "undefined behaviour"
> is really treacherous !!
> 
> Is there any way to ensure proper alignment so I don't fall into this trap
> and still benefit from maximum speed ?

I'm afraid there is no general recipe that would ensure proper alignment.
But using memcpy hasn't necessary to be "much slower".
And trading undefined behavior for a little more speed isn't a good idea in
general.

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66230

--- Comment #11 from gpnuma at centaurean dot com ---
(In reply to Markus Trippelsdorf from comment #10)
> (In reply to gpnuma from comment #8)
> > Thanks Markus I didn't think these alignment issues were actually the
> > problem, it goes a long way.
> > 
> > By doing memmoves instead of pointer cast allocations I got rid of the
> > segfault, but of course things are much slower... this "undefined behaviour"
> > is really treacherous !!
> > 
> > Is there any way to ensure proper alignment so I don't fall into this trap
> > and still benefit from maximum speed ?
> 
> I'm afraid there is no general recipe that would ensure proper alignment.
> But using memcpy hasn't necessary to be "much slower".
> And trading undefined behavior for a little more speed isn't a good idea in
> general.

Thanks, actually the code with __builtin_memmove is 30% slower compiled with
gcc 4.9.2 or 4.8 than it is with pointer cast allocations in 4.8 (4.9 can't say
because of the segfault).

However after testing with gcc 5.1 I had the pleasant surprise to see that it's
performing at the same speed as before, which means 30% faster than gcc 4.9.

30% faster is huge, you've obviously done a great job in the optimization
stages for 5.1 !