Отслеживание ошибок памяти macOS с помощью ASAN ⇐ C++

[Anonymous]

Здесь я немного размышляю в темноте. В macOS непредсказуемо/редко возникает ошибка повреждения памяти, которую мне трудно отследить.
Сбой в отладчике (с включенным ASAN), когда он происходит случайно, выглядит следующим образом:

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

==51174==ERROR: AddressSanitizer: stack-use-after-scope on address 0x000114f5cc40 at pc 0x00010f6d1576 bp 0x7ff7b0889ba0 sp 0x7ff7b0889b98
READ of size 1 at 0x000114f5cc40 thread T0
#0 0x00010f6d1575 in std::__1::basic_string::__is_long[abi:de200100]() const+0x45 (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x100060575)
#1 0x00010f6d14f8 in std::__1::basic_string::size[abi:de200100]() const+0x18 (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x1000604f8)
#2 0x00010f6e3524 in std::__1::basic_string::length[abi:de200100]() const+0x14 (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x100072524)
#3 0x00010f6a39a4 in wxString::length() const+0x14 (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x1000329a4)
#4 0x00010f6a5db4 in wxString::Length() const+0x14 (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x100034db4)
#5 0x000135e59709  ()
#6 0x00010f712c0f in _GLOBAL__sub_I_myfile.cpp+0x4f (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x1000a1c0f)
#7 0x000110631beb in ...normal stack trace from here down... (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x100fc0beb)

(Я использую wxWidgets, где, например, wxString — это тонкая оболочка вокруг std::string. На данный момент я предполагаю, что, поскольку wxWidgets широко используется и хорошо протестирован, это не проблема библиотеки, потому что я не видел, чтобы об этом сообщалось где-либо еще, и в коде wx нет ничего, что выглядело бы соучастником.)
или:

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

==2272==ERROR: AddressSanitizer: heap-use-after-free on address 0x604002385158 at pc 0x00010f6e041b bp 0x7ff7b088aea0 sp 0x7ff7b088ae98
READ of size 8 at 0x604002385158 thread T0
#0 0x00010f6e041a in std::__1::vector::size[abi:de200100]() const+0x3a (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x10006e41a)
#1 0x00010f94e254 in wxBaseObjectArray::GetCount() const+0x14 (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x1002dc254)
#2 0x00010f957c3b in Paragraph::GetText()+0x4b (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x1002e5c3b)
#3 0x000115e4085e  ()
#4 0x00010f713b9f in _GLOBAL__sub_I_myfile.cpp+0x4f (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x1000a1b9f)
#5 0x00010fc0b54d in ...normal stack trace from here down...  (/MyApp.app/Contents/MacOS/MyApp:x86_64+0x10059954d)

В любом случае «...нормальная трассировка стека...» — это некоторая случайная, но легко отслеживаемая точка в MyApp.
Когда пользователь нажимает на нее в сборке выпуска (поскольку я предполагаю, что это одно и то же), выходные данные отчета о сбоях macOS выглядят примерно так:

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

Thread 0::  Dispatch queue: com.apple.main-thread
Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib              0x7ff81929c82e __pthread_kill + 10
1   libsystem_pthread.dylib             0x7ff8192d8b5a pthread_kill + 259
2   libsystem_c.dylib                   0x7ff8191e93a6 abort + 126
3   libsystem_malloc.dylib              0x7ff8190ddbff malloc_vreport + 857
4   libsystem_malloc.dylib              0x7ff81910b84f malloc_zone_error + 183
5   libsystem_malloc.dylib              0x7ff8190f749c nanov2_guard_corruption_detected + 34
6   libsystem_malloc.dylib              0x7ff8190f7466 nanov2_allocate_outlined + 407
7   libsystem_malloc.dylib              0x7ff8190f5d4d nanov2_malloc_type + 525
8   libc++abi.dylib                     0x7ff81929071b operator new(unsigned long) + 52
9   MyApp                               0x10a028ca3 std::__1::basic_string::__init_copy_ctor_external(wchar_t const*, unsigned long) + 99

Или, если есть более интересный вариант:

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

Thread 8 Crashed::  Dispatch queue: CI::LoadLibrariesQueue
0   libsystem_kernel.dylib              0x7ff80d0f982e __pthread_kill + 10
1   libsystem_pthread.dylib             0x7ff80d135b5a pthread_kill + 259
2   libsystem_c.dylib                   0x7ff80d0463a6 abort + 126
3   libsystem_malloc.dylib              0x7ff80cf3abff malloc_vreport + 857
4   libsystem_malloc.dylib              0x7ff80cf6884f malloc_zone_error + 183
5   libsystem_malloc.dylib              0x7ff80cf5449c nanov2_guard_corruption_detected + 34
6   libsystem_malloc.dylib              0x7ff80cf54466 nanov2_allocate_outlined + 407
7   libsystem_malloc.dylib              0x7ff80cf533b6 nanov2_calloc_type + 617
8   CoreFoundation                      0x7ff80d1793ee _CFRuntimeCreateInstance + 397
9   CoreFoundation                      0x7ff80d178bb3 __CFStringCreateImmutableFunnel3 + 2542
10  CoreFoundation                      0x7ff80d1781b7 CFStringCreateWithCString + 62
11  Metal                               0x7ff819491283 MTLLibraryDataWithArchive::allocateFunctionNames() + 153
12  Metal                               0x7ff81949137c MTLLibraryDataWithArchive::functionNames() + 14
13  CoreImage                           0x7ff81a41335b invocation function for block in CI::StitchableKernels::StitchableKernels(CI::MetalContext const*) + 242
14  libdispatch.dylib                   0x7ff80cf8849a _dispatch_block_async_invoke2 + 85
15  libdispatch.dylib                   0x7ff80cf91bee _dispatch_client_callout + 6
16  libdispatch.dylib                   0x7ff80cf8245b _dispatch_lane_serial_drain + 779
17  libdispatch.dylib                   0x7ff80cf82ea9 _dispatch_lane_invoke + 382
18  libdispatch.dylib                   0x7ff80cf8bd42 _dispatch_root_queue_drain_deferred_wlh + 275
19  libdispatch.dylib                   0x7ff80cf8b705 _dispatch_workloop_worker_thread + 871
20  libsystem_pthread.dylib             0x7ff80d132869 _pthread_wqthread + 298
21  libsystem_pthread.dylib             0x7ff80d131843 start_wqthread + 15

(интересно, потому что это не поток 0 или сам MyApp, а поток CoreImage)
И вот где я нахожусь:
В трассировках стека отладчика есть вызов _GLOBAL__sub_I_myfile.cpp, который, насколько я понимаю, представляет собой статическую инициализацию чего-то в myfile.cpp. Но дело в том, что я не уверен, почему в этот момент происходит статическая инициализация, если я правильно понимаю, что она делает, и ничто в предыдущем «...нормальная трассировка стека отсюда и вниз...» не вызывает ничего, близкого к myfile.cpp. (На самом деле, myfile.cpp обычно не используется и в основном просто возвращается из любых вызовов к нему.)
В прошлом я заметил, что ASAN помечает использование стека после ошибки области с помощью «выделено здесь...» или ошибку кучи с «ранее выделено...», но в этих случаях выходные данные ASAN указывают только что-то вроде:

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

    [2976, 3016) 'ref.tmp364' (line 385)
[3056, 3096) 'ref.tmp372' (line 385)
[3136, 3176) 'msg' (line 413) 

Подробнее здесь: [url]https://stackoverflow.com/questions/79858768/tracking-down-macos-memory-errors-with-asan[/url]