we found a crash on "asm("hint 0xc" : "+r"(x17) : "r"(x16)); // autia1716"

[jetusfromchina]

when send a signal to the thread get context and used unwind unw_step，it happen on "Signal Catcher" "FinalizerDaemon" "HeapTaskDaemon" "Jit thread pool" etc

1
libUE4.so
pc 000000001011a37c
libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::stepWithDwarf(libunwind::LocalAddressSpace&, unsigned long, unsigned long, libunwind::Registers_arm64&, bool&, bool) (...\libunwind\libunwind\src\DwarfInstructions.hpp:305:11) [arm64-v8a]
2
libUE4.so
pc 0000000010119ae0
libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::step(bool) (G...\libunwind\libunwind\src\UnwindCursor.hpp:2933) [arm64-v8a]
(Inline) libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::stepWithDwarfFDE(bool) (...\libunwind\libunwind\src\UnwindCursor.hpp:1023:12)
3
libUE4.so
pc 0000000010119320
__unw_step (...\libunwind\libunwind\src\libunwind.cpp:182:14) [arm64-v8a]
4
libUE4.so
pc 000000000257a8b8
UnwindCurrent::UnwindFromContextLLVM(unsigned long, ucontext*) (...\UnwindCurrent.cpp:238:11) [arm64-v8a]
5
libUE4.so
pc 0000000002576174
BacktraceCurrent::UnwindThread(int, std::__ndk1::vector<std::__ndk1::basic_string<char, std::__ndk1::char_traits, std::__ndk1::allocator>, std::__ndk1::allocator<std::__ndk1::basic_string<char, std::__ndk1::char_traits, std::__ndk1::allocator>>>&, unsigned long) (...\BacktraceCurrent.cpp:0:0) [arm64-v8a]

[EugeneZelenko]

Could you please provide reproducer?

[jetusfromchina]

xiao mi 14 pro and android 14, we use newest unwind dump stack in UE4 game, it work well on other thread but not these "Jit thread pool||Signal Catcher||HeapTaskDaemon||FinalizerWatchd||perfetto_hprof_||ReferenceQueueD||ADB-JDWP Connec||FinalizerDaemon" when send a signal and get the context to dump the stack

[jetusfromchina]

any progress?

[HsingYun]

@Stylie777 @EugeneZelenko

Crash on VMWare client linux, compile based on the following code with GCC
https://github.com/llvm/llvm-project/tree/84c1564d1825880d463d9f85153812f1f6805289

update

The issue cannot be reproduced with clang, only with gcc.

$ clang --version
Ubuntu clang version 20.1.2 (0ubuntu1)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-20/bin

$ gcc --version
gcc (Ubuntu 14.2.0-19ubuntu2) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Host

Host: VMware Fusion on MacMini M4Pro-64G
Darwin 24.4.0 Darwin Kernel Version 24.4.0: Fri Apr 11 18:32:50 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T6041 arm64

Client

Client: Ubuntu 25.04 Arm64 (VMware, Inc. VMware20,1)
Linux hsingyun-VMware 6.14.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Sun Apr  6 14:37:51 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

$ gcc --version
gcc (Ubuntu 14.2.0-19ubuntu2) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Stack

libunwind::DwarfInstructions::stepWithDwarf DwarfInstructions.hpp:339
libunwind::UnwindCursor::stepWithDwarfFDE UnwindCursor.hpp:1046
libunwind::UnwindCursor::step UnwindCursor.hpp:3128
__unw_step libunwind.cpp:182
koko::DumpStackTrace[abi:cxx11](int, int) CXXABI.cpp:57
koko::MakeTrace Exception.cpp:29
koko::Exception::Exception Exception.cpp:32
Func3 ExceptionTest.cpp:22
Func2 ExceptionTest.cpp:24
Func1 ExceptionTest.cpp:26
ExceptionTest_ExceptionTest_Test::TestBody ExceptionTest.cpp:30
testing::internal::HandleSehExceptionsInMethodIfSupported<…> gtest.cc:2664
testing::internal::HandleExceptionsInMethodIfSupported<…> gtest.cc:2700
testing::Test::Run gtest.cc:2739
testing::TestInfo::Run gtest.cc:2885
testing::TestSuite::Run gtest.cc:3063
testing::internal::UnitTestImpl::RunAllTests gtest.cc:6054
testing::internal::HandleSehExceptionsInMethodIfSupported<…> gtest.cc:2664
testing::internal::HandleExceptionsInMethodIfSupported<…> gtest.cc:2700
testing::UnitTest::Run gtest.cc:5594
RUN_ALL_TESTS gtest.h:2334
main gtest_main.cc:64

[Stylie777]

Hi @HsingYun,
Can you please provide a reproducer for this if possible?
Thanks

[HsingYun]

$ uname -a                                                       
Linux VMware 6.14.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Sun Apr  6 14:37:51 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

$ export CC=gcc && export CXX=g++
$ mkdir build && cd build && cmake .. && make -j8 && ./crash_test

here is the reproduced code @Stylie777

---

crash.zip

---

(No debugging symbols found in ./crash_test)
(gdb) r
Starting program: /mnt/hgfs/Users/hsingyun/Develop/crash/build/crash_test 
Function(s) ^std::(move|forward|as_const|(__)?addressof) will be skipped when stepping.
Function(s) ^std::(shared|unique)_ptr<.*>::(get|operator) will be skipped when stepping.
Function(s) ^std::(basic_string|vector|array|deque|(forward_)?list|(unordered_|flat_)?(multi)?(map|set)|span)<.*>::(c?r?(begin|end)|front|back|data|size|empty) will be skipped when stepping.
Function(s) ^std::(basic_string|vector|array|deque|span)<.*>::operator.] will be skipped when stepping.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x0000fffff7f9713c in libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::stepWithDwarf(libunwind::LocalAddressSpace&, unsigned long, unsigned long, libunwind::Registers_arm64&, bool&, bool) ()
   from /mnt/hgfs/Users/hsingyun/Develop/crash/build/lib/libunwind.so.1
(gdb) bt
#0  0x0000fffff7f9713c in libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::stepWithDwarf(libunwind::LocalAddressSpace&, unsigned long, unsigned long, libunwind::Registers_arm64&, bool&, bool) ()
   from /mnt/hgfs/Users/hsingyun/Develop/crash/build/lib/libunwind.so.1
#1  0x0000fffff7f96588 in libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::stepWithDwarfFDE(bool) ()
   from /mnt/hgfs/Users/hsingyun/Develop/crash/build/lib/libunwind.so.1
#2  0x0000fffff7f96068 in libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::step(bool) ()
   from /mnt/hgfs/Users/hsingyun/Develop/crash/build/lib/libunwind.so.1
#3  0x0000fffff7f91c00 in unw_step ()
   from /mnt/hgfs/Users/hsingyun/Develop/crash/build/lib/libunwind.so.1
#4  0x0000aaaaaaac35f0 in CustomException::DumpStackTrace[abi:cxx11](int, int)
    ()
#5  0x0000aaaaaaac05f0 in CustomException::CustomException(char const*) ()
#6  0x0000aaaaaaabd7d0 in Func3() ()
#7  0x0000aaaaaaabd808 in Func2() ()
#8  0x0000aaaaaaabd81c in Func1() ()
#9  0x0000aaaaaaabd834 in main ()

[Stylie777]

Thanks - I will work on reproducing this and post my findings here for you when I do.

Initial thoughts are that as it compiles ok with clang, and not with gcc, this may be a GCC bug rather than a libunwind bug. GCC may be outputting incorrect information to the unwinder, but I cannot confirm this without looking at the output first.

[HsingYun]

Thanks @Stylie777 . Below are the assembly outputs from GCC and Clang.

Clang does not strictly adhere to the directives asm("x17") and asm("x16") to allocate variables directly into the specified registers, but instead loads the values from the stack into these registers. I'm not sure whether this behavior is normal.

However, prior to executing the hint instruction, the clang does load the correct values into registers x16 and x17.

gcc

-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -I/mnt/hgfs/Users/hsingyun/Develop/koko/libs/libunwind/libunwind/include -std=c++17 -fPIC -Werror=return-type -funwind-tables -nostdinc++ -D_DEBUG -D_LIBUNWIND_IS_NATIVE_ONLY -Wall -Wextra -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wformat-nonliteral -Wno-nullability-completeness -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wno-attributes -Wno-literal-suffix -Wno-c++14-compat -Wno-noexcept-type -Wno-suggest-override -Wno-alloc-size-larger-than -Wno-deprecated-declarations -Wno-dangling-reference -Wno-strict-overflow -Wno-maybe-uninitialized -Wno-strict-aliasing -Wno-error -pedantic -fno-rtti -fstrict-aliasing -fno-exceptions -fno-rtti

clang

-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBUNWIND_LINK_DL_LIB -D_LIBUNWIND_LINK_PTHREAD_LIB -I/mnt/hgfs/Users/hsingyun/Develop/koko/libs/libunwind/libunwind/include -std=c++17 -fPIC -Werror=return-type -funwind-tables -nostdinc++ -D_DEBUG -D_LIBUNWIND_IS_NATIVE_ONLY -Wall -Wextra -Wnewline-eof -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral -Wzero-length-array -Wdeprecated-redundant-constexpr-static-def -Wno-nullability-completeness -Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override -Wno-error -pedantic -fno-rtti -fstrict-aliasing -fno-exceptions -fno-rtti

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: None (jetusfromchina)

when send a signal to the thread get context and used unwind unw_step，it happen on "Signal Catcher" "FinalizerDaemon" "HeapTaskDaemon" "Jit thread pool" etc

1
libUE4.so
pc 000000001011a37c
libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::stepWithDwarf(libunwind::LocalAddressSpace&, unsigned long, unsigned long, libunwind::Registers_arm64&, bool&, bool) (...\libunwind\libunwind\src\DwarfInstructions.hpp:305:11) [arm64-v8a]
2
libUE4.so
pc 0000000010119ae0
libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::step(bool) (G...\libunwind\libunwind\src\UnwindCursor.hpp:2933) [arm64-v8a]
(Inline) libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm64>::stepWithDwarfFDE(bool) (...\libunwind\libunwind\src\UnwindCursor.hpp:1023:12)
3
libUE4.so
pc 0000000010119320
__unw_step (...\libunwind\libunwind\src\libunwind.cpp:182:14) [arm64-v8a]
4
libUE4.so
pc 000000000257a8b8
UnwindCurrent::UnwindFromContextLLVM(unsigned long, ucontext*) (...\UnwindCurrent.cpp:238:11) [arm64-v8a]
5
libUE4.so
pc 0000000002576174
BacktraceCurrent::UnwindThread(int, std::__ndk1::vector<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::allocator<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>>&, unsigned long) (...\BacktraceCurrent.cpp:0:0) [arm64-v8a]

[c-rhodes]

can you confirm if the crash at compile-time or runtime?

I noticed there's a SIGILL (illegal instruction) in the last stack trace:

Program received signal SIGILL, Illegal instruction.

which suggests your host doesn't support the instruction. I had a quick look and AUTIA1716 (ref) requires FEAT_PAuth introduced in armv8.3, does your system have this feature?