search

gabime / spdlog

Fast C++ logging library.
Other
23.94k stars 4.5k forks source link

SIGBUS after compilation onto ARM-32 running Android #1436

Closed DroidDragon closed 4 years ago

DroidDragon commented 4 years ago

I have a project that is wrapping C++ libraries that include spdlog. The code is bundled into an .so file, then into an .aar, whence it is consumed by an Android app written in Java.

Building this mess for a 64-bit platform has been working fine. Building for a 32-bit ARM yields a binary that raises an illegal instruction in pattern_formatter.h, line 752, attempting to make this call to handleflag():

if (++it != end)
 {
         handle_flag_(*it);
 }

This seems to affect all 32 bit platforms.

Many other libraries that are linked into the same .aar seem to be working fine.

AFAICT, this happens the first time spdlog is touched.

tt4g commented 4 years ago

The spdlog you are using looks old. The latest pattern_formatter.h has only about 100 lines. Try the latest version v1.5.0.

tt4g commented 4 years ago

I don't specialize in Android development, but the combination of Android and ARM seems to have problems with struct (class) alignment.

domWalters commented 2 months ago

I appear to have hit this when using a spdlog::error during destruction of a class.

This was on a 64 bit AArch64 CPU (Compiled with gcc in Xilinx Vitis 2023.1).

I haven't investigated it enough yet, so I may update this when I am able to look into it.

domWalters commented 2 months ago

This is the end of the gdb backtrace:

Thread 7 "app" received signal SIGBUS, Bus error.
[Switching to Thread 0xfffff554f180 (LWP 25115)]
std::__atomic_base<int>::load (__m=std::memory_order_relaxed, this=0xaaa000553d81) at /opt/Xilinx/Vitis/2023.1/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-xilinx-linux/usr/include/c++/12.2.0/bits/atomic_base.h:488
488     /opt/Xilinx/Vitis/2023.1/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-xilinx-linux/usr/include/c++/12.2.0/bits/atomic_base.h: No such file or directory.
(gdb) backtrace
#0  std::__atomic_base<int>::load (__m=std::memory_order_relaxed, this=0xaaa000553d81)
    at /opt/Xilinx/Vitis/2023.1/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-xilinx-linux/usr/include/c++/12.2.0/bits/atomic_base.h:488
#1  spdlog::sinks::sink::should_log (this=0xaaa000553d79, msg_level=spdlog::level::warn)
    at ../../../.cache/spdlog/include/spdlog/sinks/sink-inl.h:13
#2  0x0000fffff56fa248 in spdlog::logger::sink_it_ (this=0xaaaaaaffb8c0, msg=...)
    at ../../../.cache/spdlog/include/spdlog/logger-inl.h:137
#3  0x0000fffff56fa168 in spdlog::logger::log_it_ (this=0xaaaaaaffb8c0, log_msg=..., log_enabled=true,
    traceback_enabled=false) at ../../../.cache/spdlog/include/spdlog/logger-inl.h:128
#4  0x0000fffff5743ca0 in spdlog::logger::log_<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (this=0xaaaaaaffb8c0, loc=..., lvl=spdlog::level::warn, fmt=...) at ../../../.cache/spdlog/include/spdlog/logger.h:332
#5  0x0000fffff5736840 in spdlog::logger::log<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (this=0xaaaaaaffb8c0, loc=..., lvl=spdlog::level::warn, fmt=...) at ../../../.cache/spdlog/include/spdlog/logger.h:80
#6  0x0000fffff572ae58 in spdlog::logger::log<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (this=0xaaaaaaffb8c0, lvl=spdlog::level::warn, fmt=...) at ../../../.cache/spdlog/include/spdlog/logger.h:85
#7  0x0000fffff571c6fc in spdlog::logger::warn<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (this=0xaaaaaaffb8c0, fmt=...) at ../../../.cache/spdlog/include/spdlog/logger.h:145
#8  0x0000fffff571018c in spdlog::warn<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (
    fmt=...) at ../../../.cache/spdlog/include/spdlog/spdlog.h:173
domWalters commented 2 months ago

Looking into this slightly today, this might be down to a multithreading issue on my end.

Found these two forum posts that are semi related: