原生 arm64 和原生 Intel/rosetta2 x86_64 的“返回后使用堆栈内存”的区别

如何解决原生 arm64 和原生 Intel/rosetta2 x86_64 的“返回后使用堆栈内存”的区别

我使用我的代码库（C/C++ 和 Swift）收到一条奇怪的消息。代码本身太大而无法发布，但我想听听人们认为可能是什么原因。

我在 M1 Apple Silicon 芯片上本机运行相同的代码，没有任何问题。我已打开所有诊断程序：

当我在基于 Intel 的 Mac 和/或 Rosetta2 下使用它时，乐趣就开始了。（所有系统都是 Big Sur）。

Vithanco(83162,0x20400de00) malloc: enabling scribbling to detect mods to free blocks
Vithanco(83162,0x20400de00) malloc: nano zone abandoned due to inability to preallocate reserved vm space.
applicationDidFinishLaunching
objc[83162]: Class _NSZombie_NSSimpleRegularExpressionCheckingResult is implemented in both ?? (0x60400017ab90) and ?? (0x60400016ffd0). One of the two will be used. Which one is undefined.
=================================================================
==83162==ERROR: AddressSanitizer: stack-use-after-return on address 0x0001105fee00 at pc 0x000101fbd30f bp 0x000308d4eb70 sp 0x000308d4eb68
WRITE of size 8 at 0x0001105fee00 thread T0
==83162==WARNING: invalid path to external symbolizer!
==83162==WARNING: Failed to use and restart external symbolizer!
    #0 0x101fbd30e in textfont_dict_open+0x44e (/Users/(deleted)/Library/Developer/Xcode/DerivedData/...-gwcenzuufsseezetprookmoioioy/Build/Products/Debug/.../Contents/MacOS/Vithanco:x86_64+0x1012b630e)
    #1 0x1026f3036 in loadGraphvizLibraries+0x156 (/Users/(deleted)/Library/Developer/Xcode/DerivedData/Vithanco-gwcenzuufsseezetprookmoioioy/Build/Products/Debug/Vithanco.app/Contents/MacOS/Vithanco:x86_64+0x1019ec036)
    #2 0x1026f618c in globalinit_33_2FCABEB9B9698DE37811B48DE0525A0F_func0+0xc (/Users/(deleted)/Library/Developer/Xcode/DerivedData/Vithanco-gwcenzuufsseezetprookmoioioy/Build/Products/Debug/Vithanco.app/Contents/MacOS/Vithanco:x86_64+0x1019ef18c)
    #3 0x1102400af in _dispatch_client_callout+0x7 (/usr/lib/system/introspection/libdispatch.dylib:x86_64+0x40af)

错误堆栈中还有很多内容，但没有太大用处。

我只是想知道：这可能是什么情况？为什么相同的代码只会在一种架构上运行到 Use of Stack Memory After Return 中？之前在英特尔上运行过相同的代码。那么，这是 macOS、编译器问题还是其他问题？

解决方法

我使用了这个声明：

extern struct _dt_s textfont_dict_open(GVC_t * gvc);

代替

extern struct _dt_s * textfont_dict_open(GVC_t * gvc);

有趣的是，虽然我从未使用过该方法的结果，但两种架构如何导致截然不同的结果。