[
https://issues.apache.org/jira/browse/ARROW-13608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neal Richardson updated ARROW-13608:
------------------------------------
Summary: [R] symbol initialization appears to be depending on undefined
behavior (was: R symbol initialization appears to be depending on undefined
behavior)
> [R] symbol initialization appears to be depending on undefined behavior
> -----------------------------------------------------------------------
>
> Key: ARROW-13608
> URL: https://issues.apache.org/jira/browse/ARROW-13608
> Project: Apache Arrow
> Issue Type: Bug
> Components: R
> Environment: x86_64, linux
> Reporter: Phillip Cloud
> Priority: Major
>
> The R bindings for arrow are triggering a segfault when running
> {{library(arrow)}}.
> After a large amount of investigation by [~jonkeane], [~npr], [~bkietz],
> [~apitrou] and myself, we narrowed the problem down to what appears to be
> dependence on the order of static initialization.
> The order of static initialization in C++ is indeterminate
> ([https://en.cppreference.com/w/cpp/language/initialization], see the
> "Dynamic Initialization" section), which implies that if a {{static A}}
> depends on a {{static B}} declared and initialized in another translation
> unit, it is perfectly legal for the compiler to initialize {{A}} _before_
> {{B}} and thus trigger undefined behavior due to {{A}} using an uninitialized
> {{B}}.
> This is manifesting as a segmentation fault.
> A "prose-level" trace is as follows:
> 1. The R bindings construct symbols in
> [https://github.com/apache/arrow/blob/master/r/src/symbols.cpp#L79].
> 2. Those binding initialize a number of {{r_vector}} s, with this overload:
> [https://github.com/r-lib/cpp11/blob/master/inst/include/cpp11/r_vector.hpp#L363-L369]
> 3. The overload references the static variable {{preserved}} and calls its
> {{insert}} method.
> 4. {{insert}} dereferences a null pointer here:
> [https://github.com/r-lib/cpp11/blob/master/inst/include/cpp11/protect.hpp#L316]
> ({{list_}} specifically).
> I think the solution lies inside of `cpp11`, and that is to use the
> [Construct on First Use
> idiom|https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use] to
> initialize `preserved` instead of using `static struct` like it does now
> ([https://github.com/r-lib/cpp11/blob/master/inst/include/cpp11/protect.hpp#L301]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
