C++ library for storing and printing backtraces.
Home Page: https://boost.org/libs/stacktrace
Library for storing and printing backtraces.
Boost.Stacktrace is a part of the Boost C++ Libraries.
| @ | Build | Tests coverage | More info |
|---|---|---|---|
| Develop branch: |  |
 |
details... |
| Master branch: |  |
 |
details... |
Latest developer documentation
Distributed under the Boost Software License, Version 1.0.
I'm building my application on Apline linux and get the following error in the translation unit that includes stacktrace.hpp:
/root/COExternals/3rdParty/Install/[email protected]@openssl-1.0.2h-4-x86_64-static-Clang-4.0.0-Ninja-73006cdeef24/include/boost/stacktrace/detail/safe_dump_posix.ipp:36:63: error: use of undeclared identifier 'S_IFREG'
const int fd = ::open(file, O_CREAT | O_WRONLY | O_TRUNC, S_IFREG | S_IWUSR | S_IRUSR);
^
1 error generated.
I've fixed locally by adding include <sys/stat.h> in case when build is on linux platform, but possibly it should be added inside stacktrace library.
A typical stack trace with the library, even when you've defined BOOST_STACKTRACE_USE_LIBUNWIND and linked with -lunwind, is far from being specific enough:
Backtrace:
0# traced::traced() +0x28
1# with_trace<std::logic_error>::with_trace<char const (&) [44]>(char const (&) [44]) +0x3E
2# oops(int) +0x60
3# bar(int) +0x73
4# foo(int) +0x19
5# bar(int) +0x67
6# foo(int) +0x19
7# bar(int) +0x67
8# foo(int) +0x19
9# bar(int) +0x67
10# foo(int) +0x19
11# bar(int) +0x67
12# foo(int) +0x19
13# bar(int) +0x67
14# foo(int) +0x19
15# main +0x13
16# __libc_start_main +0xF0
17# _start +0x29
18#
How do I know what these offsets mean? where are the source filenames and line numbers?
When you compile code with -g, the binary has information about positions in source files of different instructions. That's why something like libSegfault can work and be used to produce more proper traces, e.g.
Backtrace:
/lib/libSegFault.so[0xb7f9e100]
??:0(??)[0xb7fa3400]
/usr/include/c++/4.3/bits/stl_queue.h:226(std::queue<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::deque<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::push(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&))[0x805647a]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/player.cpp:73(Player::input(std::basic_string<char, std::char_traits<char>, std::allocator<char> >))[0x805377c]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:159(Socket::Read())[0x8050698]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:413(ServerSocket::Read())[0x80507ad]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:300(ServerSocket::poll())[0x8050b44]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/main.cpp:34(main)[0x8049a72]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7d1b775]
/build/buildd/glibc-2.9/csu/../sysdeps/i386/elf/start.S:122(_start)[0x8049801]
(that's after C++ name demangling). I think that's the kind of trace that developers would expect...
rev: 8d11eeb.
when using b2.exe in MSVC-14.1 as below, error occured.
b2 variant=debug,release link=static runtime-link=static threading=multi --with-stacktrace
error: link=shared together with runtime-link=static is not allowed
error: such property combination is either impossible
error: or too dangerious to be of any use
At least in my case (GCC 6.3.0, sjlj exception handling, Window 8.1 Pro 64-bit, build targeting 32-bit environment) it compiles and works fine. On the contrary _Unwind_Backtrace in the same environment compiles but does not work.
It would be good if this were at least configurable if there are still cases when RtlCaptureStackBackTrace is not available.
Would it be possible to add information regarding the line numbers and the filenames related to the functions appearing in the stacktrace?
libbacktrace exists on my system.
After I had built boost with default options, I found boost_stacktrace_backtrace was not built, but libboost_stacktrace_addr2line was generated.
Moved from https://svn.boost.org/trac10/ticket/13300
I use BOOST_BACKTRACE_USE_WINDBG here for printing stacktraces in my MinGW compiled application. If I print the stacktrace in the debug version of my application, I will get a complete stacktrace. If I print the stacktrace in the release version (-fno-omit-frame-pointer and debug symbols not stripped), some levels are missing.
This is the stack of the release version that is shown in the QtCreator debugger:
This is the stack trace that is printed by boost stacktrace for the release version:
This is the stack trace that is printed by boost stacktrace for the debug version:
So the QtCreator debugger can extract a more detailed stacktrace from the release build than the boost stacktrace library. Is this normal or is this an issue?
S_IFREG flag is undefined for Android. It looks like the flag is intended to be used with stat but not with open and could be safely removed.
include/boost/stacktrace/detail/libbacktrace_impls.hpp
#ifdef BOOST_STACKTRACE_BACKTRACE_INCLUDE_FILE
# include BOOST_STACKTRACE_BACKTRACE_INCLUDE_FILE
#else
# include <backtrace.h>
#endif
On Xenial it could be found in /usr/lib/gcc/x86_64-linux-gnu/5/include/backtrace.h
Hello everyone,
For Boost.Stacktrace builds using ICC on Windows got error:
.\b2 --build-type=complete --with-stacktrace toolset=intel-17.0-vc14 variant=release link=shared threading=multi runtime-link=shared address-model=64 -j1 -d2 -q
<snip>
"libs\stacktrace\build\..\src\windbg.cpp" -Fo"bin.v2\libs\stacktrace\build\intel-vc14-win-17.0\release\threading-multi\windbg.obj" -TP /O2 /Ob2 /W4 /GR /MD /Zc:forScope /Zc:wchar_t /favor:blend /nologo /Qwn5 /Qwd985 -Qoption,c,--arg_dep_lookup /Qvc14 -Qpchi- /wd4675 /EHs -c
-DBOOST_ALL_NO_LIB=1
-DBOOST_STACKTRACE_DYN_LINK=1
-DNDEBUG
"-I."
compile-c-c++ bin.v2\libs\stacktrace\build\intel-vc14-win-17.0\release\threading-multi\windbg.obj
call "C:\Users\test\AppData\Local\Temp\b2_intel-win_17.0_iclvars_intel64 vs2015.cmd" > nul
icl @"bin.v2\libs\stacktrace\build\intel-vc14-win-17.0\release\threading-multi\windbg.obj.rsp"
windbg.cpp
.\boost/stacktrace/detail/collect_unwind.ipp(17): catastrophic error: cannot open source file "unwind.h"
#include <unwind.h>
^
compilation aborted for libs\stacktrace\build\..\src\windbg.cpp (code 4)
...failed compile-c-c++ bin.v2\libs\stacktrace\build\intel-vc14-win-17.0\release\threading-multi\windbg.obj...
...failed updating 1 target...
...updated 9 targets...
Reproduced for builds using ICC with <Debug|Release><Shared|Static> configurations.
Not reproduced for builds using mingw-w64 or MSVC.
Just in case, ICC trying imitate MSVC on Windows and GCC on *Linux platforms. Its installation on Windows contain file unwind.h, which has references to SEP Development Kit, but seems it's not intended for Windows builds.
Environment:
Alexander
Please, move boost/detail/winapi/capture_stack.hpp to boost/stacktrace and also update the file contents to:
boost::detail::winapi namespaceBOOST_DETAIL_WINAPI prefix in macrosMoved from https://svn.boost.org/trac10/ticket/13529
See https://ci.appveyor.com/project/boostorg/boost/build/1.0.4217-master
msvc-12.0 and msvc-14.1 hang, msvc-14.0 fails.
Superproject CI builds have been failing for a while with
In file included from ./boost/stacktrace/detail/frame_unwind.ipp:25:0,
from libs/stacktrace/build/../src/backtrace.cpp:15:
./boost/stacktrace/detail/libbacktrace_impls.hpp: In member function ‘void boost::stacktrace::detail::to_string_using_backtrace::prepare_function_name(const void*)’:
./boost/stacktrace/detail/libbacktrace_impls.hpp:108:13: error: invalid conversion from ‘void (*)(void*, uintptr_t, const char*, uintptr_t, uintptr_t) {aka void (*)(void*, long unsigned int, const char*, long unsigned int, long unsigned int)}’ to ‘backtrace_syminfo_callback {aka void (*)(void*, long unsigned int, const char*, long unsigned int)}’ [-fpermissive]
);
^
./boost/stacktrace/detail/libbacktrace_impls.hpp: In function ‘std::string boost::stacktrace::detail::name_impl(const void*)’:
./boost/stacktrace/detail/libbacktrace_impls.hpp:155:9: error: invalid conversion from ‘void (*)(void*, uintptr_t, const char*, uintptr_t, uintptr_t) {aka void (*)(void*, long unsigned int, const char*, long unsigned int, long unsigned int)}’ to ‘backtrace_syminfo_callback {aka void (*)(void*, long unsigned int, const char*, long unsigned int)}’ [-fpermissive]
);
^
see f.ex. https://travis-ci.org/boostorg/boost/jobs/421389489
While building under MXE (MinGW) I get the following error:
In file included from ../../source/stacktrace/include/boost/stacktrace/frame.hpp:197:0,
from ../../source/stacktrace/include/boost/stacktrace.hpp:15,
from ../../source/app/main.cpp:10:
../../source/stacktrace/include/boost/stacktrace/detail/frame_unwind.ipp:24:22: fatal error: execinfo.h: No such file or directory
As I can see execinfo.h is Linux specific. Can you suggest any workaround (for MinGW)?
Hello:
I write a test program and want to write dump file on windows, but it doesn't work, I think it has something wrong in my code, but I don't know why , can someone help me :
my whole code, on Windows 10 ,VS2010 boost 1.67:
#include <signal.h>
#include <boost/stacktrace.hpp>
void my_signal_handler(int signum)
{
::signal(signum, SIG_DFL);
boost::stacktrace::safe_dump_to( "./backtrace.dump");
::raise(SIGABRT);
}
int main()
{
::signal(SIGSEGV, &my_signal_handler);
::signal(SIGABRT, &my_signal_handler);
//do something;
std::terminate();
}
is it some macro i missed ?
thanks.
First - let me thank you for the library.
Following the documentation I created a simple Win32 console program. The program contains a recursive function to compute the Fibonnaci number. I included a call to dump the stack at the start of the function.
The function looks like:
int fib(n)
{
cout << boost::stacktrace::stacktrace();
if (0 == n)
return 0;
if (1 == n)
return 1;
return fib(n - 1) + fib(n - 2);
}
I call the function with:
for (int iii = 0; iii < 13; ++iii)
cout << iii << ": " << fib(iii) << '\n';
Update: in testing I added a condition to only write out the stack after 10 levels of recursion. To better seen the effect of memory growth and progressive slow-down I've updated the code to remove the condition.
After a few calls, the output of the stack track to the console slows to a crawl and the process memory grows to ~700MB.
I compiled the program using Visual Studio 2015 Update 5. The rest of the boost libraries came from version 1.62.
/// Outputs stacktrace in a human readable format to std::string; unsafe to use in async handlers.
template <class Allocator>
std::string to_string(const basic_stacktrace<Allocator>& bt) {
if (bt) {
return boost::stacktrace::detail::to_string(&bt.as_vector()[0], bt.size());
} else {
return std::string();
}
}
I'm trying to use stacktrace on android without boost library and i get
"frame_unwind.ipp:10:28: fatal error: boost/config.hpp: No such file or directory".
Environment:
VS 2017 + Windows Server 2016
Issue description:
We build and run test for boost. And we found a tests failed to run after boost submodule stacktrace updated from c63afe (master) to d6f0c6 (boostorg/boost@4ca9fa2). It seems the test failed due to "Performing configuration checks". Could you please take a look?
ErrorMessage:
[executing command] .\b2 -j4 variant=release cxxflags="/Oy-" --build-dir=..\out\x86rel libs\stacktrace\test
Performing configuration checks
- default address-model : 32-bit (cached)
- default architecture : x86 (cached)
- symlinks supported : yes (cached)
D:/Boost/src/tools/build/src/build\feature.jam:327: in validate-feature from module feature
error: unknown feature ""
We use the MinGW toolchain that ships with the Qt Libraries. This is the output of gcc -v
Thread model: posix
gcc version 5.3.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)
Using BOOST_STACKTRACE_USE_WINDBG_CACHED results in the following compiler error:
../boost/stacktrace/detail/frame_msvc.ipp(167): fatal error C1189: #error: Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED.
These are the compiller settings:
-O0 -g3 -Wall -c -fmessage-length=0 -std=c++14
Hello everyone,
For Boost.Stacktrace builds using mingw-w64 got error:
gcc.compile.c++ bin.v2\libs\stacktrace\build\gcc-mingw-6.3.0\release\threading-multi\windbg_cached.o
"g++" -O3 -finline-functions -Wno-inline -Wall -pedantic -mthreads -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_STACKTRACE_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2\libs\stacktrace\build\gcc-mingw-6.3.0\release\threading-multi\windbg_cached.o" "libs\stacktrace\build\..\src\windbg_cached.cpp"
In file included from libs\stacktrace\build\..\src\windbg_cached.cpp:10:0:
./boost/stacktrace/detail/frame_msvc.ipp:167:72: warning: missing terminating ' character
# error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED.
^
./boost/stacktrace/detail/frame_msvc.ipp:167:5: error: #error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED.
# error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED.
^~~~~
In file included from ./boost/detail/winapi/file_management.hpp:17:0,
from ./boost/stacktrace/detail/safe_dump_win.ipp:20,
from ./boost/stacktrace/safe_dump_to.hpp:206,
from ./boost/stacktrace/frame.hpp:20,
from ./boost/stacktrace/detail/frame_msvc.ipp:15,
from libs\stacktrace\build\..\src\windbg_cached.cpp:10:
./boost/detail/winapi/overlapped.hpp:39:9: warning: ISO C++ prohibits anonymous structs [-Wpedantic]
};
^
...failed gcc.compile.c++ bin.v2\libs\stacktrace\build\gcc-mingw-6.3.0\release\threading-multi\windbg_cached.o...
...failed updating 1 target...
...updated 14074 targets...
Reproduced for:
<Debug|Release><Shared|Static> configurations.Not reproduced for:
Environment:
Alexander
It's a bit more lightweight than dbgeng/windbg (I think it's used by them) and it wouldn't have the issues with COM (It's what Rust uses for backtraces in the MSVC version).
Note that I think you must also have symsrv.dll (Distributed with windbg) for symbol loading with it to work. The dbghelp.dll installed with Windows is often unable to get symbols probably because it doesn't have that dll available or maybe it just doesn't support it at all.
MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/ms679309(v=vs.85).aspx
P.S. I guess that you must have dbgeng.dll and all it's dependencies for the windbg config to work (i.e. You must vendor them, add them to PATH, etc...), might want to document that.
EDIT: I saw in some pr that you said you don't use dbghelp because it's single threaded. But I think windbg uses it under the hood... They even have warnings against using dbghelp in windbg extensions... It's possible that you might be affected by it's limitations despite using the dbgeng/windbg API.
There is also the option of msdia (https://msdn.microsoft.com/en-us/library/x93ctkx8.aspx) which you get with MSVC, but I'm not sure about licensing and how easy it is to use it to parse backtraces. It's another COM api but it can be used directly though an undocumented export in it's dll (NoRegCoCreate).
Here:
Line 36 in ba2f260
I am trying to compile a program that uses Boost.Stacktrace and get the following error:
% g++ -g -I/tmp/boost/include -L/tmp/boost/lib -DBOOST_STACKTRACE_LINK -DBOOST_STACKTRACE_USE_BACKTRACE -lboost_stacktrace_backtrace -ldl -lbacktrace stacktrace-test.cpp -o stacktrace-test
In file included from /tmp/boost/include/boost/stacktrace/frame.hpp:20:0,
from /tmp/boost/include/boost/stacktrace.hpp:15,
from stacktrace-test.cpp:2:
/tmp/boost/include/boost/stacktrace/safe_dump_to.hpp:15:10: fatal error: boost/stacktrace/detail/push_options.pp: No such file or directory
#include <boost/stacktrace/detail/push_options.pp>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
I am using Stacktrace library version that is included in Boost 1.65.0 release. Boost was built whith the following commands:
./bootstrap.sh
./b2 --prefix=/tmp/boost --with-stacktrace install
Resulting installation indeed misses files boost/stacktrace/detail/push_options.pp and boost/stacktrace/detail/pop_options.pp. Is this a bug, or am I doing something wrong?
Hello! I have small example with boost::stacktrace: just setup handler, crash and write trace.
Everything is ok, but stacktrace doesn't contains source file names and lines numbers:
Crashed:
0# 0x0040166D in C:\workspace\build-botsapp-Desktop_Qt_5_8_0_MinGW_32bit-Debug\booststacktracetest\debug\booststacktracetest.exe
1# 0x75D97790 in C:\Windows\System32\msvcrt.dll
How to fix this issue? I tried several configurations: BOOST_STACKTRACE_USE_WINDBG, BOOST_STACKTRACE_USE_BACKTRACE, BOOST_STACKTRACE_USE_LIBUNWIND. Last one even doesn't write stacktrace.
Code:
#include <signal.h>
#include <cstdlib>
#include <iostream>
#define BOOST_STACKTRACE_USE_BACKTRACE
#include <boost/stacktrace.hpp>
void my_signal_handler(int signum)
{
::signal(signum, SIG_DFL);
boost::stacktrace::stacktrace st;
std::cout << "Crashed:\n" << st << std::endl;
std::_Exit(-1);
}
void crash()
{
throw std::runtime_error("test");
}
int main(int argc, char *argv[])
{
::signal(SIGSEGV, &my_signal_handler);
::signal(SIGABRT, &my_signal_handler);
crash();
}
I have used the new docs to test a few configurations of Stacktrace on Msys2. It works better than in Boost 1.65, so thank you for that, but still there are almost no function names printed, on all configurations. I said "almost", because the names are displayed for Windows system libraries in WINDBG and WINDBG_CACHED configs. However, I noticed the missing names can be manually extracted afterwards from addresses using addr2line utility.
I attached full logs of configuring and compilation of libraries in the file logs.txt.
I hope the following testing will be useful to you.
I have setup and tested on two computers with a following config:
Msys2 MinGW x64
G++ 7.2.0 x64
Boost 1.66 x64 from package mingw64/mingw-w64-x86_64-boost
Windows 10 x64
For the initial setup of Msys2 environment please see my previous comment.
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ g++ -g -o stacktrace-basic.exe main.cpp
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ ./stacktrace-basic.exe
0# 0x00000000004033A1 in D:\dev\project\test\stacktrace-boost166-test\stacktrace-basic.exe
1# 0x00000000004015A2 in D:\dev\project\test\stacktrace-boost166-test\stacktrace-basic.exe
2# 0x00000000004015FE in D:\dev\project\test\stacktrace-boost166-test\stacktrace-basic.exe
3# 0x00000000004013F7 in D:\dev\project\test\stacktrace-boost166-test\stacktrace-basic.exe
4# 0x000000000040152B in D:\dev\project\test\stacktrace-boost166-test\stacktrace-basic.exe
5# 0x00007FFF33042774 in C:\WINDOWS\System32\KERNEL32.DLL
6# 0x00007FFF331A0D51 in C:\WINDOWS\SYSTEM32\ntdll.dll
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ addr2line -Cfpi -e ./stacktrace-basic.exe 0x00000000004015A2
foo() at D:\dev\project\test\stacktrace-boost166-test/main.cpp:6
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ addr2line -Cfpi -e ./stacktrace-basic.exe 0x00000000004015FE
main at D:\dev\project\test\stacktrace-boost166-test/main.cpp:12
I followed MinGW specific instructions except for the two last points ("using gcc : 6..." and "b2.exe...") as I understand they are only needed for non-header-only builds of Stacktrace.
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ g++ -g -DBOOST_STACKTRACE_USE_BACKTRACE -I/d/dev/project/3rdparty/libbacktrace -o stacktrace-backtrace.exe main.cpp -L/d/dev/project/3rdparty/libbacktrace/ -lbacktrace -ldl
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ ./stacktrace-backtrace.exe
0# 0x0000000000408C71 in D:\dev\project\test\stacktrace-boost166-test\stacktrace-backtrace.exe
1# 0x00000000004015A2 in D:\dev\project\test\stacktrace-boost166-test\stacktrace-backtrace.exe
2# 0x00000000004015FE in D:\dev\project\test\stacktrace-boost166-test\stacktrace-backtrace.exe
3# 0x00000000004013F7 in D:\dev\project\test\stacktrace-boost166-test\stacktrace-backtrace.exe
4# 0x000000000040152B in D:\dev\project\test\stacktrace-boost166-test\stacktrace-backtrace.exe
5# 0x00007FFF33042774 in C:\WINDOWS\System32\KERNEL32.DLL
6# 0x00007FFF331A0D51 in C:\WINDOWS\SYSTEM32\ntdll.dll
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ addr2line -Cfpi -e ./stacktrace-backtrace.exe 0x00000000004015A2
foo() at D:\dev\project\test\stacktrace-boost166-test/main.cpp:6
Here I stumbled upon an error during libtool step:
Fazer@Fazer-PC MINGW64 /d/dev/project/3rdparty/gcc/libbacktrace (master)
$ ./libtool --mode=install /usr/bin/install -c libbacktrace.la '/d/dev/project/3rdparty/gcc/libbacktrace'
libtool: install: /usr/bin/install -c .libs/libbacktrace.lai /d/dev/project/3rdparty/gcc/libbacktrace/libbacktrace.la
/usr/bin/install: cannot stat '.libs/libbacktrace.lai': No such file or directory
I assumed it only tried to put files into correct folders, so I changed the location in the command below to gcc/libbacktrace/.libs:
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ g++ -g -DBOOST_STACKTRACE_USE_BACKTRACE -I/d/dev/project/3rdparty/gcc/libbacktrace -o stacktrace-backtrace-gcc.exe main.cpp -L/d/dev/project/3rdparty/gcc/libbacktrace/.libs -lbacktrace -ldl
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ ./stacktrace-backtrace-gcc.exe
0# 0x0000000000408DC1 in D:\dev\project\test\stacktrace-boost166-test\stacktrace-backtrace-gcc.exe
1# 0x00000000004015A2 in D:\dev\project\test\stacktrace-boost166-test\stacktrace-backtrace-gcc.exe
2# 0x00000000004015FE in D:\dev\project\test\stacktrace-boost166-test\stacktrace-backtrace-gcc.exe
3# 0x00000000004013F7 in D:\dev\project\test\stacktrace-boost166-test\stacktrace-backtrace-gcc.exe
4# 0x000000000040152B in D:\dev\project\test\stacktrace-boost166-test\stacktrace-backtrace-gcc.exe
5# 0x00007FFF33042774 in C:\WINDOWS\System32\KERNEL32.DLL
6# 0x00007FFF331A0D51 in C:\WINDOWS\SYSTEM32\ntdll.dll
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ addr2line -Cfpi -e ./stacktrace-backtrace-gcc.exe 0x00000000004015A2
foo() at D:\dev\project\test\stacktrace-boost166-test/main.cpp:6
I am aware of your comment that WINDBG* configs only sometimes work, but I wanted to check them all.
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ g++ -g -DBOOST_STACKTRACE_USE_WINDBG -o stacktrace-windbg.exe main.cpp -lole32 -ldbgeng
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ ./stacktrace-windbg.exe
0# 0x0000000000403511 in stacktrace_windbg
1# 0x000000000040167E in stacktrace_windbg
2# 0x00000000004016DA in stacktrace_windbg
3# 0x00000000004013F7 in stacktrace_windbg
4# 0x000000000040152B in stacktrace_windbg
5# _BaseThreadInitThunk in KERNEL32
6# _RtlUserThreadStart in ntdll
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ addr2line -Cfpi -e ./stacktrace-windbg.exe 0x000000000040167E
foo() at D:\dev\project\test\stacktrace-boost166-test/main.cpp:6
On first try I got an error that thread_local is not supported:
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ g++ -g -std=c++11 -DBOOST_STACKTRACE_USE_WINDBG_CACHED -o stacktrace-windbg-cached.exe main.cpp
In file included from D:/app/msys64/mingw64/include/boost/stacktrace/frame.hpp:59:0,
from D:/app/msys64/mingw64/include/boost/stacktrace.hpp:15,
from main.cpp:1:
D:/app/msys64/mingw64/include/boost/stacktrace/detail/frame_msvc.ipp:167:5: error: #error Your compiler does not support C++11 thread_local storage. It`s impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED.
# error Your compiler does not support C++11 thread_local storage. It`s impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED.
^~~~~
That surprised me because it should be supported since GCC 4.8. I found it was disabled by this:
// in D:\app\msys64\mingw64\include\boost\config\compiler\gcc.hpp:306
#ifdef __MINGW32__
// Currently (June 2017) thread_local is broken on mingw for all current compiler releases, see
// https://sourceforge.net/p/mingw-w64/bugs/527/
// Not setting this causes program termination on thread exit.
#define BOOST_NO_CXX11_THREAD_LOCAL
#endif
That bug report states it is broken only on some configurations of MinGW, not all of them. For some reason in my x64 environment both __MINGW32__ and __MINGW64__ are defined (which seems like there is a bug in Boost.Config, MinGW or Msys2), so I tested in a separate project that thread_local indeed works and undefined it:
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
echo -e "#undef __MINGW32__\n$(cat main.cpp)" > main.cpp
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ g++ -g -std=c++11 -DBOOST_STACKTRACE_USE_WINDBG_CACHED -o stacktrace-windbg-cached.exe main.cpp -lole32 -ldbgeng
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ ./stacktrace-windbg-cached.exe
0# 0x0000000000403511 in stacktrace_windbg_cached
1# 0x000000000040167E in stacktrace_windbg_cached
2# 0x00000000004016DA in stacktrace_windbg_cached
3# 0x00000000004013F7 in stacktrace_windbg_cached
4# 0x000000000040152B in stacktrace_windbg_cached
5# _BaseThreadInitThunk in KERNEL32
6# _RtlUserThreadStart in ntdll
Fazer@Fazer-PC MINGW64 /d/dev/project/test/stacktrace-boost166-test
$ addr2line -Cfpi -e ./stacktrace-windbg-cached.exe 0x000000000040167E
foo() at D:\dev\project\test\stacktrace-boost166-test/main.cpp:7
I know the docs state only POSIX compilers are supported, but I tried it for the sake of completeness. As in my previous bug report comment, it requires not present file sys/wait.h and additionally I learned that MinGW doesn't provide ::fork syscall, so it's impossible to use this configuration.
I have another problem with building project using stacktrace
1>c:\project\libs\vcpkg\installed\x64-windows\include\boost\stacktrace\detail\collect_msvc.ipp(22): error C2039: 'RtlCaptureStackBackTrace': is not a member of 'boost::detail::winapi'
1>c:\project\libs\vcpkg\installed\x64-windows\include\boost\detail\winapi\detail\deprecated_namespace.hpp(22): note: see declaration of 'boost::detail::winapi'
1>c:\project\libs\vcpkg\installed\x64-windows\include\boost\stacktrace\detail\collect_msvc.ipp(22): error C3861: 'RtlCaptureStackBackTrace': identifier not found
is this vcpkg (boost 1.66) problem?
http://apolukhin.github.io/stacktrace/index.html
in README.md
Reported here: https://svn.boost.org/trac10/ticket/13178
I attempted to build this library on macOS (Xcode 7.3.1) and found that there were a few includes missing:
example/assert_handler.cpp: missing <cstdlib> for std::exit()example/terminate_handler.cpp: missing <cstdlib> for std::exit()include/boost/stacktrace/detail/backend_linux.hpp: missing <signal.h> for kill()Aside from that the code seems to work great on macOS (tested on 10.11.6 with Xcode 7.3.1 -- clang-703.0.31) using the Linux backend, based on my limited testing using your examples and test code.
Thanks!
In backend_windows.hpp: try_init_com (line 83) I'm getting an internal exception in "dbgeng.dll". Here is the exact error message: "Exception thrown at 0x0F46D7BD (dbgeng.dll) in XXXX.exe: 0xC000001D: Illegal Instruction".
The thing is though, the stack still generates correctly after this, it's just incredibly slow (and not really practically usable for my case), so I'm assuming it's due to this.
I'll try to mess around with it a bit, but some help here would be great! :)
I'm on windows 10, 64 bit. Also note I'm not really doing anything special here, just calling boost::stacktrace::stacktrace and writing to a stringstream like in the examples.
The other language have such feature to get the stack trace when exception happens. It will be very helpful for debugging.
Hello,
When attempting to use the header only version of Stacktrace, I get the following linker error:
Undefined symbols for architecture armv7:
"__Unwind_Backtrace", referenced from:
boost::stacktrace::detail::this_thread_frames::collect(void const**, unsigned long, unsigned long) in libmylib.a(Error.cpp.o)
ld: symbol(s) not found for architecture armv7
I did look in the libSystem.tbd and the __Unwind_Backtrace symbol is only defined for arm64.
The workaround is to define the BOOST_STACKTRACE_USE_NOOP macro. Is there another way to workaround the problem?
Essentially, the stacktrace module (eventually) includes the windows.h header, which then defines macros for min and max, which then conflict with the std::min(), std::min() and std::numeric_limits<T>::min/max() functions, resulting in compilation errors.
This issue was also observed/fixed for the ASIO module: https://svn.boost.org/trac10/ticket/3901
A workaround for now is to just #define NOMINMAX when building the project, however it would be much better if the stacktrace module defined this itself. Perhaps this could be defined in a new detail/config.hpp file (similarly to ASIO)?
In environment Windows 7 x64, VS2017, boost 1.64.
Running the example 'terminate_handler.cpp' generates an access violation seg fault.
line 27 of stacktrace/detail/safe_dump_win.ipp has '0' as the penultimate parameter in the call to WriteFile. This should be a pointer to a DWORD for the WriteFile function to write the number of bytes written to file.
Changing this line to these two:
boost::detail::winapi::DWORD_ written =0; if (!boost::detail::winapi::WriteFile(fd, frames, static_cast<boost::detail::winapi::DWORD_>(sizeof(native_frame_ptr_t) * frames_count), &written, 0)) {
resolves the seg fault.
Pete
We used the stacktrace in our cross platform development (Win,Linux, Mac). On Linux/Mac it works as expected but on Windows there are some issues:
For windows we build our code using cmake+MinGW in msys2 environment as header only lib.
__CRT_UUID_DECL(IDebugClient,0x27fe5639,0x8407,0x4f47,0x83,0x64,0xee,0x11,0x8f,0xb0,0x8a,0xc8);
__CRT_UUID_DECL(IDebugControl,0x5182e668,0x105e,0x416e,0xad,0x92,0x24,0xef,0x80,0x04,0x24,0xba);
__CRT_UUID_DECL(IDebugSymbols,0x8c31e98c,0x983a,0x48a5,0x90,0x16,0x6f,0xe5,0xd6,0x67,0xa9,0x50);
Also it appears that symbols are not demangled. Thus we patched it by adding boost::core::demangle appending additional underscore before symbol.
Look at the patch with changes that we have made to make it working for us.
In the patch.diff.txt there are additional hacking to make it work with boost 1.60
Many Thanks!
not the bugreport, rather just for the record. I couldn't make it work on my win 7 and tried several dbgeng.dll versions to no avail until I installed fresh win ddk which did the trick for me. side effect is extra dependencies on DbgModel.dll and dbghelp.dll I've had to put into target directory to let application start. guess this could be reflected in docs as windows specific details
When I build and run throwing_st.cpp (using libunwind), it yields the following output (only including the first few lines):
Backtrace:
0# traced::traced() +0x28
1# with_trace<std::logic_error>::with_trace<char const (&) [44]>(char const (&) [44]) +0x3E
2# oops(int) +0x60
3# bar(int) +0x73
-- etc. etc. --
I believe that the first two lines should not be part of the stack trace; it should, IMO, start with the point of the throw, and not follow the implementation of the exception.
I believe currently the biggest "competitor" to Boost.Stacktrace is Backward-cpp. Its main strength is automatic printing of source code context for every frame in the stack trace.
That difference doesn't seem like much at a glance, but it changes the way you develop your programs. You no longer have to manually copy-paste locations from the trace to check what code was in there. Of course the users can automate this functionality themselves, but it would lead to a lot of duplication across projects.
The only downside of Backward-cpp that I noticed so far is lack of support for Windows. Boost.Stacktrace already works there, so if this feature request was implemented, it could improve popularity of this library.
If you are more interested in pushing Boost.Stacktrace as a standard, the proposed feature could also be included in the paper.
Thanks in advance for your consideration.
Since boost shall be platform independent and QNX 7 is a Unix variant, would there be support for QNX 7? I tried to use boost/stacktrace with QNX 7. Just including boost/stacktrace.hpp resulted in a compilation error because the internally included backtrace.h (from QNX 7) did not resolve the required symbols. Comparing QNX7's backtrace.h with Windows' backtrace.h made obvious that it could not compile.
While building 1.68.0 beta 1 on x86_64 linux cross-compiling to Windows 64 bits with minw-w64 + g++ 8.2.0, I get this warning:
"x86_64-w64-mingw32-g++-8.2.0" -I/softs/win64-mingw-8.2.0/release/iconv/include -I/softs/win64-mingw-8.2.0/release/gettext/include -I/softs/win64-mingw-8.2.0/release/bzip2/include -I/softs/win64-mingw-8.2.0/release/zlib/include -I/softs/win64-mingw-8.2.0/release/jpeg-turbo/include -I/softs/win64-mingw-8.2.0/release/xz/include -I/softs/win64-mingw-8.2.0/release/tiff/include -I/softs/win64-mingw-8.2.0/release/png/include -std=c++14 -O2 -DNDEBUG -m64 -mthreads -O3 -finline-functions -Wno-inline -Wall -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_FILESYSTEM_NO_DEPRECATED -DBOOST_LOG_WITHOUT_EVENT_LOG -DNDEBUG -I"." -c -o "bin.v2/libs/stacktrace/build/gcc-8.2.0/release/link-static/target-os-windows/threading-multi/basic.o" "libs/stacktrace/build/../src/basic.cpp"
In file included from ./boost/winapi/file_management.hpp:17,
from ./boost/stacktrace/detail/safe_dump_win.ipp:20,
from ./boost/stacktrace/safe_dump_to.hpp:210,
from ./boost/stacktrace/frame.hpp:20,
from ./boost/stacktrace/detail/frame_unwind.ipp:15,
from libs/stacktrace/build/../src/basic.cpp:14:
./boost/winapi/overlapped.hpp:38:9: warning: ISO C++ prohibits anonymous structs [-Wpedantic]
};
^
Hi
I am seeing an performance issue in 2 usages of bookst::stacktrace.
Source file: backtrace.cpp
Steps: ./runme (Compile the source file and run the executable to get time taken in dumping
stacktraces by different approaches)
Attached : fie.tar.gz containg abobe 2 files - backtrace.cpp and runme.
The first approach below of using boost::stacktrace() below is 45 times faster.
The real time is dumped by executing the above ‘runme’ script:
bt_final_boost1 Time Taken (sec): 0.02
bt_final_boost2 Time Taken (sec): 0.93
Regards
Deepak
We use the MinGW toolchain that ships with the Qt Libraries. This is the output of gcc -v
Thread model: posix
gcc version 5.3.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)
Using BOOST_STACKTRACE_USE_WINDBG with MinGW results in linker errors because the following libraries are required: ole32 and dbgeng. This is not documented anywhere.
I'm developing a solution where the call stack is stored in XML file, so I call the name(), source_file(), and source_line() functions for each frame, I takes about 45 seconds to complete the loop on stack depth of about 70 levels.
I just downloaded a zip of the master branch, unzipped and built with:
g++ --std=c++14 -o throwing throwing_st.cpp -g -I ../include/ -ldl
on a system with Boost 1.60 installed. Running the resulting binary, I get:
'i' must not be greater than zero in oops()
Backtrace:
0# ?? at 0x00401C70
1# ?? at 0x00401FF7
2# ?? at 0x00402148
3# ?? at 0x004014E6
4# ?? at 0x0040159D
5# ?? at 0x004015B8
6# ?? at 0x00401591
7# ?? at 0x004015B8
8# ?? at 0x00401591
9# ?? at 0x004015B8
10# ?? at 0x00401591
11# ?? at 0x004015B8
12# ?? at 0x00401591
13# ?? at 0x004015B8
14# ?? at 0x00401591
15# ?? at 0x004015B8
16# ?? at 0x004015CD
17# __libc_start_main
18# ?? at 0x004013B9
Why don't I see at least function names in the trace?
Hi,
we use the MinGW toolchain that ships with the Qt Libraries. This is the output of gcc -v
Thread model: posix
gcc version 5.3.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)
The stacktrace does not print the functions names. This is the test programm
int functionA()
{
std::cout << boost::stacktrace::stacktrace() << std::endl;
return 0;
}
int functionB()
{
return functionA();
}
int main()
{
functionB();
return 0;
}This is the output using BOOST_STACKTRACE_USE_WINDBG:
0# 0x00401B08 in EventTest
1# 0x00401B66 in EventTest
2# 0x00401B78 in EventTest
3# 0x004013E2 in EventTest
This is the output using BOOST_STACKTRACE_USE_BACKTRACE:
0# 0x00401A40 in C:\projects_neon\EventTest\Debug\EventTest.exe
1# 0x00401A9E in C:\projects_neon\EventTest\Debug\EventTest.exe
2# 0x00401AB0 in C:\projects_neon\EventTest\Debug\EventTest.exe
3# 0x004013E2 in C:\projects_neon\EventTest\Debug\EventTest.exe
So no functions names are printed.
I'm trying to save a stacktrace to raw memory using the safe_dump_to(void *, std::size_t) function, however the function returns the number of stack frames (plus the termination frame) written - not the number of bytes written.
This means that when I come to read this data, I have no idea what to put in the size field of stacktrace::from_dump(const void *, std::size_t, const allocator_type &). At first I assumed that I could use sizeof(boost::stacktrace::frame) * frames, but the frame type contains heap allocated memory (std::strings) so that won't work.
This SSCE demonstrates the problem:
#include <iostream>
#include <boost/stacktrace.hpp>
int main()
{
auto buf = std::array<char, 8192>{};
const auto size = boost::stacktrace::safe_dump_to(buf.data(), buf.size());
const auto st = boost::stacktrace::stacktrace::from_dump(buf.data(), size);
std::cout << "ST from dump (" << size << " bytes): " << st << std::endl
<< "ST: " << boost::stacktrace::stacktrace{} << std::endl;
return EXIT_SUCCESS;
}
It outputs:
ST from dump (4 bytes):
ST: 0# 0x00000000004016A7 in ./a.out
1# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
2# 0x0000000000401759 in ./a.out
The second 'ST' line is just to show what is expected. The first line fails because I'm trying to treat the frame count as a byte size, which it obviously isn't.
So how is the API supposed to be used?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.