id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
13481	Strict aliasing is causing SIGSEGV on ARM Cortex-A15 when using GCC6	Piotr Podusowski <piotr.podusowski@…>	Douglas Gregor	"Hello,
I've been tracking a crach after upgrading GCC to 6.4 which was caused by corruption of the object stored inside `boost::function`.

I think that the root cause for this is in the `function_buffer` storage. You see, there is a char member there with the intention of ""relax aliasing constraints"" as it states in the comment but if my understanding of the standard is correct, it doesn't really do that. Quote from the C++:

{{{
If a program attempts to access the stored value of an object through a glvalue of other than one of the
following types the behavior is undefined: 52
— the dynamic type of the object,
— a cv-qualified version of the dynamic type of the object,
— a type similar (as defined in 4.4) to the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type
of the object,
— an aggregate or union type that includes one of the aforementioned types among its elements or non-
static data members (including, recursively, an element or non-static data member of a subaggregate
or contained union),
— a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
— a char or unsigned char type.
}}}

There is indeed a `char` type along other things that may be aliased safely, but `function_buffer` is an `union` with `char` member so it falls into:

{{{
an aggregate or union type that includes one of the **aforementioned** types
}}}

so the `function_buffer` itself can't be aliased. There was similar bug on GCC: 77686 (I'm unable to put links here) which was fixed by applying `may_alias` attribute on their `function_buffer` counterpart. Seems reasonable but after applying it to `function_buffer` it was still failing but after reading GCC docs I think I've found out why:

{{{
may_alias
Accesses through **pointers to types** with this attribute are not subject to type-
based alias analysis, but are instead assumed to be able to alias any other type
of objects. In the context of section 6.5 paragraph 7 of the C99 standard, an
lvalue expression dereferencing such a pointer is treated like having a character
type.
}}}

and there is `BOOST_FUNCTION_FUNCTION::move_assign` function which does:

{{{
if (this->has_trivial_copy_and_destroy())
    this->functor = f.functor;
}}}

and as it doesn't operate on the pointers, `may_alias` seems to be simply ignored. So two things seems to fixing it (I hope they fix it, since the bug if quite ""delicate"" and it's easy to hide it by changing the code that doesn't seem relevant):

1) use `gnu::may_alias` on `function_buffer` and assign it trough some helper like this instead of `union`s assign operator:

{{{
template<class T> void alias_safe_assign(T & dst, T & src)
{
    dst = src;
}
}}}

there is Richard's comment on GCC bugtracker: 77686#c12 where he's noted about `std::swap` having a references so it seems to matter.

2) operate on `data` member directly since it has relaxed aliasing requirements by being a `char`. This doesn't even require GNU extensions.:

{{{
std::memcpy(this->functor.data, f.functor.data, sizeof(boost::detail::function::function_buffer));
}}}

Of course, putting a `may_alias` on the functor type itself (the one that I'm assigning to `boost::function` object) or putting this type into `function_buffer` also fixes this.


----


I'm compiling the attached testcase using
{{{
arm-cortexa15-linux-gnueabihf-g++ (GCC) 6.4.1 20170811
}}}

and `-O2 -fPIC`

Br, Piotr."	Bugs	new	To Be Determined	function	Boost 1.66.0	Problem