Sigsegv in boost :: stacktrace :: frame :: source_line при доступе к хранилищу Think_local на macOS 15 Clang 17 Intel; П ⇐ C++

[Anonymous]

У нас есть библиотека C ++ 20, которая собирает несколько модулей Boost и статически связывает свои объектные файлы в нашу общую библиотеку. Одним из этих модулей является boost.stacktrace. Мы скомпилируем эту библиотеку и тестовое приложение, которое использует ее, на многочисленных платформах : MacOS 14 Clang 16 ARM, MacOS 15 Clang 17 ARM и MacOS 15 Clang 17 Intel; GCC 8, 9, 11, 13 и 14 в Rhel 8, Rhel9, Ubuntu 22.04 и Ubuntu 24.04; и Windows 10, 11, 2022 и 2025 с MSVC 2022. А затем для всего этого, мы составляем отдельный OPT и отладку (

Код: Выделить всё

-g

) Библиотеки и тестовые приложения.
На платформах POSIX (так что исключая Windows для продолжительности этого вопроса), мы ссылаемся на Libbacktrace , и мы строим и ссылаемся на Boost.StackTrace.backtrace . На Ubuntu это использует предоставленную GCC Libacktrace . На RHEL и MacOS Libacktrace не предоставлен, поэтому мы компилируем Libbacktrace из источника и используем это. Мы получаем ожидаемую, полезную информацию для StackTraces без ошибок. Однако на MacOS 15 (только) Clang 17 (только) Intel (только) Opt (только), вызов Boost :: StackTrace :: Frame :: Source_line () или source_file () или name () segfaults (

Код: Выделить всё

EXC_BAD_ACCESS (SIGSEGV)

), и он последовательно разбирается каждый раз. Это не происходит на руке. Это не происходит на Clang 16. Это не происходит на MacOS 15 Clang 17 Intel Debug . Только macOS 15 Clang 17 Intel opt (что делает трассировку по источнику усерднее, но я думаю, что у меня есть).
Вот первые два кадра из отчета о сбое консоли Macos. Третий кадр - это вызов нашего кода в Source_line () :

Код: Выделить всё

0   libdyld.dylib                    0x7ff817a8ef96 _tlv_get_addr + 3
1   libNameOfMySharedLibrary.dylib   0x1096e44db boost::stacktrace::frame::source_line() const + 27
3   [our code]
...
< /code>
Даже без имен файлов и номеров строк я получил бы на сборке отладки, это решает. _TLV_GET_ADDR 

- это функция, специально используемая для Thread_local Storage. Это оставляет только один возможный стек вызовов, который может генерировать это конкретное условие (сгенерировано вручную): < /p>

Код: Выделить всё

0   _tlv_get_addr in libdylib.dylib
1   thread_local in ???
2   boost::stacktrace::detail::construct_state(...) at boost/stacktrace/detail/libbacktrace_impls.hpp:104
3   boost::stacktrace::frame::source_line() at boost/stacktrace/detail/libbacktrace_impls.hpp:229
4   [our code]
...
< /code>
Ссылки на вышеуказанные источники: < /p>
[list]
[*]boost/stacktrace/detail/libbacktrace_impls.hpp:104

[*]

Код: Выделить всё

boost/stacktrace/detail/libbacktrace_impls.hpp:229

[/list]
Вот некоторая дополнительная информация из отчета об аварии, мало что я понимаю:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007ff914b8b9e0
Exception Codes: 0x0000000000000001, 0x00007ff914b8b9e0

Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [11903]

VM Region Info: 0x7ff914b8b9e0 is not in any region. Bytes after previous region: 1961314785 Bytes before following region: 16938528
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
__LINKEDIT 7ff895bb3000-7ff89fd17000 [161.4M] r--/r-- SM=COW dyld shared cache combined __LINKEDIT
---> GAP OF 0x75e9c000 BYTES
unused __TEXT 7ff915bb3000-7ff935a5b000 [510.7M] r-x/r-x SM=COW unused unknown system shared lib __TEXT
< /code>
Итак, вся эта информация выброшена там, я не знаю, к кому сообщить об этой проблеме. Это A: < /p>

ошибка Boost (я так не думаю)? < /Li>
ошибка macOS? /> < /ol>

Подробнее здесь: https://stackoverflow.com/questions/797 ... -local-sto