[clang] Segmentation fault when initializing const std::string

[sekaiacg]

system:
ArchLinux

clang version:

clang version 21.1.4
Target: x86_64-pc-linux-gnu

gcc version:
15.2.1 20250813 (GCC)

description:
After compiling and running with clang, a segmentation fault occurred, but it ran normally after compiling with gcc. I found the cause after debugging with gdb. I have provided the source code for testing and hope to get some help.

gcc

./build/test
p=en-US
skkk: ~DesktopPlatform

clang

./build/test
Segmentation fault         (core dumped) ./build/test

gdb:

(gdb) where
#0  0x0000000000405cd0 in std::char_traits<char>::assign (__c1=@0x4f8b40: 0 '\000', 
    __c2=<error reading variable: Cannot access memory at address 0x0>)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1/../../../../include/c++/15.2.1/bits/char_traits.h:352
#1  0x0000000000405ae8 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy (__d=0x4f8b40 <brls::Platform::APP_LOCALE_DEFAULT[abi:cxx11]+16> "", __s=0x0, __n=1)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1/../../../../include/c++/15.2.1/bits/basic_string.h:451
#2  0x0000000000405910 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<true> (this=0x4f8b30 <brls::Platform::APP_LOCALE_DEFAULT[abi:cxx11]>, __str=0x0, 
    __n=0)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1/../../../../include/c++/15.2.1/bits/basic_string.tcc:298
#3  0x000000000040571c in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x4f8b30 <brls::Platform::APP_LOCALE_DEFAULT[abi:cxx11]>, __str=...)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1/../../../../include/c++/15.2.1/bits/basic_string.h:617
#4  0x0000000000405145 in __cxx_global_var_init.1(void) ()
    at test/platform.hpp:18

test sources:

test.zip

[frederick-vs-ja]

Slightly reduced (Godbolt link).

#include <string>

const std::string str1 = "en-US";
const std::string str2 = str1;

struct S {
  static inline std::string str3 = str2;
};

int main() {}

Seems only happening with Clang + libstdc++. Note that all-zero representation is invalid for libstdc++'s std::string.

There seem dynamic initialization differences between Clang and GCC, see example. Perhaps it's better to use static variable inside function body to avoid the initialization order problem.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: SK (sekaiacg)

**system:** `ArchLinux`

clang version:

clang version 21.1.4
Target: x86_64-pc-linux-gnu

gcc version:
15.2.1 20250813 (GCC)

description:
After compiling and running with clang, a segmentation fault occurred, but it ran normally after compiling with gcc. I found the cause after debugging with gdb. I have provided the source code for testing and hope to get some help.

gcc

./build/test
p=en-US
skkk: ~DesktopPlatform

clang

./build/test
Segmentation fault         (core dumped) ./build/test

gdb:

(gdb) where
#<!-- -->0  0x0000000000405cd0 in std::char_traits&lt;char&gt;::assign (__c1=@<!-- -->0x4f8b40: 0 '\000', 
    __c2=&lt;error reading variable: Cannot access memory at address 0x0&gt;)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1/../../../../include/c++/15.2.1/bits/char_traits.h:352
#<!-- -->1  0x0000000000405ae8 in std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;::_S_copy (__d=0x4f8b40 &lt;brls::Platform::APP_LOCALE_DEFAULT[abi:cxx11]+16&gt; "", __s=0x0, __n=1)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1/../../../../include/c++/15.2.1/bits/basic_string.h:451
#<!-- -->2  0x0000000000405910 in std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;::_M_construct&lt;true&gt; (this=0x4f8b30 &lt;brls::Platform::APP_LOCALE_DEFAULT[abi:cxx11]&gt;, __str=0x0, 
    __n=0)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1/../../../../include/c++/15.2.1/bits/basic_string.tcc:298
#<!-- -->3  0x000000000040571c in std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;::basic_string (this=0x4f8b30 &lt;brls::Platform::APP_LOCALE_DEFAULT[abi:cxx11]&gt;, __str=...)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1/../../../../include/c++/15.2.1/bits/basic_string.h:617
#<!-- -->4  0x0000000000405145 in __cxx_global_var_init.1(void) ()
    at test/platform.hpp:18

test sources:

test.zip

[frederick-vs-ja]

It seems that [basic.start.dynamic]/3 indicates that, given the following translation unit:

#include <string>

std::string s1 = "too-long-to-be-statically-initialized"; // assuming dynamically initialized
inline std::string s2 = s1;
std::string s3 = s2;

where s2 is not defined elsewhere, the initialization order may be either (s1, s2, s3) or (s2, s1, s3). The program won't behave as expected if the implementation chooses the latter.

The order problem won't appear if all of s1, s2, and s3 are inline.

[zygoloid]

Right. The rules were designed to allow an implementation to assume that each inline variable may be defined in additional translation units, which may be initialized first; therefore it's valid to move the initialization of an inline variable before an ordered initializer (as if that other hypothetical translation unit were initialized first).

However, while this isn't a conformance problem, as a quality of implementation issue and for GCC compatibility it might make sense to retain the relative order of ordered and partially-ordered initializers.

From a user-education perspective, the guidance was intended to be: don't mark variables inline unless you intend to define them in multiple translation units (eg, you're putting them in a header file). But unfortunately that doesn't work so well for static data members.

[zygoloid]

That said... it looks like Clang doesn't actually even guarantee that the initialization order is one of the two valid ones. I don't see anything that prevents an initialization order of (s1, s3, s2) in the LLVM IR that Clang generates.

If we keep the current emission scheme in general (which I think aims to use COMDAT magic to deduplicate dynamic initializers at link time), should we be assigning an init priority of something less than 65535 for the initializer of the inline variable, to ensure it's not initialized after a non-inline global variable that references it?

[shafik]

Also see: #61028