ianlancetaylor / libbacktrace

A C library that may be linked into a C/C++ program to produce symbolic backtraces

libbacktrace

A C library that may be linked into a C/C++ program to produce symbolic backtraces

Initially written by Ian Lance Taylor [email protected].

This is version 1.0. It is likely that this will always be version 1.0.

The libbacktrace library may be linked into a program or library and used to produce symbolic backtraces. Sample uses would be to print a detailed backtrace when an error occurs or to gather detailed profiling information. In general the functions provided by this library are async-signal-safe, meaning that they may be safely called from a signal handler.

The libbacktrace library is provided under a BSD license. See the source files for the exact license text.

The public functions are declared and documented in the header file backtrace.h, which should be #include'd by a user of the library.

Building libbacktrace will generate a file backtrace-supported.h, which a user of the library may use to determine whether backtraces will work. See the source file backtrace-supported.h.in for the macros that it defines.

As of October 2020, libbacktrace supports ELF, PE/COFF, Mach-O, and XCOFF executables with DWARF debugging information. In other words, it supports GNU/Linux, *BSD, macOS, Windows, and AIX. The library is written to make it straightforward to add support for other object file and debugging formats.

The library relies on the C++ unwind API defined at https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html This API is provided by GCC and clang.

libbacktrace's Issues

`backtrace_pcinfo` yields mixed relative and absolute pathes

https://github.com/ianlancetaylor/libbacktrace/blob/master/dwarf.c#L2874

Absolute paths are returned when no line info is found, relative ones for all other cases. The code that creates an abs path from the relative one is only invoked when ln == NULL. What is the intuition behind that? I think it would be better to always return absolute paths, or always return relative ones and make comp_dir available to the user.

Related: athre0z/color-backtrace#2

Windows: No such file or directory when running app instead of app.exe

If I type in cmd app then backtrace doesn't work since there is no app file. If I run app.exe everything works fine. Is this a bug or feature?

There could be a windows-only code which would check if passed filename is without extension, and if so it would try attaching ".exe".

Also, I'm willing to implement it :)

macho_add_fat() has wrong offset calculation

I first reported this at GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973

The issue is in macho_add_fat() in calculating the offset for a given arch. If !is_64, then the offset is retrieved as a uint32_t, and currently it is cast into a uint64_t before calling bswap64 (if swapped is true, which is the case here). That's wrong, and it should be bswap32 that is called, before casting to a wider type.

The patch below fixes it:

diff --git a/libbacktrace/macho.c b/libbacktrace/macho.c
index bd737226ca6..5974d8d8a5b 100644
--- a/libbacktrace/macho.c
+++ b/libbacktrace/macho.c
@@ -797,9 +797,13 @@ macho_add_fat (struct backtrace_state *state, const char *filename,
       uint32_t fcputype;
 
       if (is_64)
-	memcpy (&fat_arch,
-		(const char *) arch_view.data + i * arch_size,
-		arch_size);
+	{
+	  memcpy (&fat_arch,
+		  (const char *) arch_view.data + i * arch_size,
+		  arch_size);
+	  if (swapped)
+	    fat_arch.offset = __builtin_bswap64 (fat_arch.offset);
+	}
       else
 	{
 	  struct macho_fat_arch fat_arch_32;
@@ -809,7 +813,10 @@ macho_add_fat (struct backtrace_state *state, const char *filename,
 		  arch_size);
 	  fat_arch.cputype = fat_arch_32.cputype;
 	  fat_arch.cpusubtype = fat_arch_32.cpusubtype;
-	  fat_arch.offset = (uint64_t) fat_arch_32.offset;
+	  if (swapped)
+	    fat_arch.offset = (uint64_t) __builtin_bswap32(fat_arch_32.offset);
+	  else
+	    fat_arch.offset = (uint64_t) fat_arch_32.offset;
 	  fat_arch.size = (uint64_t) fat_arch_32.size;
 	  fat_arch.align = fat_arch_32.align;
 	  fat_arch.reserved = 0;
@@ -821,14 +828,9 @@ macho_add_fat (struct backtrace_state *state, const char *filename,
 
       if (fcputype == cputype)
 	{
-	  uint64_t foffset;
-
 	  /* FIXME: What about cpusubtype?  */
-	  foffset = fat_arch.offset;
-	  if (swapped)
-	    foffset = __builtin_bswap64 (foffset);
 	  backtrace_release_view (state, &arch_view, error_callback, data);
-	  return macho_add (state, filename, descriptor, foffset, match_uuid,
+	  return macho_add (state, filename, descriptor, fat_arch.offset, match_uuid,
 			    base_address, skip_symtab, error_callback, data,
 			    fileline_fn, found_sym);
 	}

Without the patch, macho_add_fat fails when called on macOS 10.15 system libraries. With the patch, everything works fine!

pecoff implementation stripping underscores fails with c++ stacktraces

The following line causes underscores to be stripped from function names:

libbacktrace/pecoff.c

Line 439 in 5a99ff7

/* Strip leading '_'. */

For example boost::stacktrace will run a demangle on the returned symbols from libbacktrace. Without the leading underscore function names will not be demangled. See an example:

Function name in COFF symbol table:
_ZN3foo3Bar6fooBarEv

Function name returned from backtrace_syminfo with COFF search function:
ZN3foo3Bar6fooBarEv

While the former can be demangled to foo::Bar::fooBar() the latter cant.

What is the reason for stripping the leading underscore? Would it be possible to avoid this?

Consider provide a simple and standard way to output stack trace text

Consider provide a simple and standard way to output stack trace text

extern int backtrace_standard (struct backtrace_state *state, int skip, char** buffer, backtrace_error_callback error_callback, void *data);

doesn't work with clang

At least with later versions of clang, I get a .rel.debug_info section that actually puts the strp offsets into the .debug_info section, and because libbacktrace doesn't read the relocations, all my strings are just "clang version 9.0.0-svn351420-1~exp1 (trunk)" (which is the string at .debug_str 0x0 offset)

Wrong library name in fmt.pc when building Debug.

The wrong library name is configured in fmt.pc file when with CMAKE_BUILD_TYPE=Debug.

As a result

$pkg-config --libs fmt

Returns -lfmt however the library name is actually "fmtd". The solution is to configure fmt.pc via variable. For example
...
prefix=@CMAKE_INSTALL_PREFIX@
exec_prefix=@CMAKE_INSTALL_PREFIX@
libdir=@CMAKE_INSTALL_FULL_LIBDIR@
includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
library=@FMT_LIBRARY_NAME@

Name: fmt
Description: A modern formatting library
Version: @FMT_VERSION@
Libs: -L${libdir} -l${library}
Cflags: -I${includedir}

Alternately change:

CMakeLists.txt:183

set_target_properties(fmt PROPERTIES
VERSION ${FMT_VERSION} SOVERSION ${CPACK_PACKAGE_VERSION_MAJOR}
DEBUG_POSTFIX d)

It seems unnecessary to have different names for library builds?

Segfault when used on ELF binary with section headers stripped

When generating a backtrace for an ELF binary with section headers stripped, there's a segfault here:

libbacktrace/elf.c

Lines 2798 to 2800 in 5c88e09

	shstrhdr = &shdrs[shstrndx - 1];
	shstr_size = shstrhdr->sh_size;
	shstr_off = shstrhdr->sh_offset;

Assuming shstrndx is nonzero can lead to underflow.

Please consider tagging the repository with version

Automated systems discover new versions using tags, and notify port maintainers about new versions.
Ports of projects with tagless repositories are less likely to be updated.

Configuring with any autoconf version other then 2.69 fails

Hello,

Running autoreconf, with autoconf 2.71, fails with the following error:

configure.ac:33: error: Please use exactly Autoconf 2.69 instead of 2.71.

The cause are the following lines:

libbacktrace/config/override.m4

Lines 30 to 48 in 4f57c99

	dnl Ensure exactly this Autoconf version is used
	m4_ifndef([_GCC_AUTOCONF_VERSION],
	[m4_define([_GCC_AUTOCONF_VERSION], [2.69])])
	dnl Test for the exact version when AC_INIT is expanded.
	dnl This allows to update the tree in steps (for testing)
	dnl by putting
	dnl m4_define([_GCC_AUTOCONF_VERSION], [X.Y])
	dnl in configure.ac before AC_INIT,
	dnl without rewriting this file.
	dnl Or for updating the whole tree at once with the definition above.
	AC_DEFUN([_GCC_AUTOCONF_VERSION_CHECK],
	[m4_if(m4_defn([_GCC_AUTOCONF_VERSION]),
	m4_defn([m4_PACKAGE_VERSION]), [],
	[m4_fatal([Please use exactly Autoconf ]_GCC_AUTOCONF_VERSION[ instead of ]m4_defn([m4_PACKAGE_VERSION])[.])])
	])
	m4_define([AC_INIT], m4_defn([AC_INIT])[
	_GCC_AUTOCONF_VERSION_CHECK
	])

What is the reason only 2.69 is allowed? Does the configure script use undocumented features?
Would it be ok to remove these lines?

C++ unwind API link invalid

The link to the C++ unwind API in the readme.md file explanation is invalid.

relocation support?

I'd like to use this library to load dwarf data from object files on disk, and it seems that this will need relocation support.

Are you aware of any code to do that, that could be added to the library?

Version

Hi,

When packaging libbacktrace as an unofficial Arch Linux package, I could not find a version number. This is handy for packaging. Is it version 0.1, 1.0 or something else?

• Package in AUR: https://aur.archlinux.org/packages/backtrace/

I also wrote a pkg-config file, if you should be interested:

backtrace.pc:

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: backtrace
Description: Produce symbolic backtraces
Version: 1.0
Libs: -L${libdir} -lbacktrace
Cflags: -I${includedir}

Best regards,
Alexander Rødseth

Unresolved path to libbacktrace, for gollvm project, on Windows 10

I am currently experiencing an issue on Windows 10 (32bit):

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=-stdlib=libc++ -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DGOLLVM_DEFAULT_LINKER=lld -G Ninja ../llvm-project/llvm
-- The C compiler identification is Clang 10.0.0 with GNU-like command-line
-- The CXX compiler identification is Clang 10.0.0 with GNU-like command-line
-- The ASM compiler identification is Clang
-- Found assembler: C:/Program Files/LLVM/bin/clang.exe
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang.exe
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Program Files/LLVM/bin/clang++.exe
-- Check for working CXX compiler: C:/Program Files/LLVM/bin/clang++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for dlfcn.h
-- Looking for dlfcn.h - not found
-- Looking for errno.h
-- Looking for errno.h - found
-- Looking for fcntl.h
-- Looking for fcntl.h - found
-- Looking for link.h
-- Looking for link.h - not found
-- Looking for malloc/malloc.h
-- Looking for malloc/malloc.h - not found
-- Looking for signal.h
-- Looking for signal.h - found
-- Looking for sys/ioctl.h
-- Looking for sys/ioctl.h - not found
-- Looking for sys/mman.h
-- Looking for sys/mman.h - not found
-- Looking for sys/param.h
-- Looking for sys/param.h - not found
-- Looking for sys/resource.h
-- Looking for sys/resource.h - not found
-- Looking for sys/stat.h
-- Looking for sys/stat.h - found
-- Looking for sys/time.h
-- Looking for sys/time.h - not found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for termios.h
-- Looking for termios.h - not found
-- Looking for unistd.h
-- Looking for unistd.h - not found
-- Looking for valgrind/valgrind.h
-- Looking for valgrind/valgrind.h - not found
-- Looking for fenv.h
-- Looking for fenv.h - found
-- Looking for FE_ALL_EXCEPT
-- Looking for FE_ALL_EXCEPT - found
-- Looking for FE_INEXACT
-- Looking for FE_INEXACT - found
-- Looking for mach/mach.h
-- Looking for mach/mach.h - not found
-- Looking for histedit.h
-- Looking for histedit.h - not found
-- Looking for CrashReporterClient.h
-- Looking for CrashReporterClient.h - not found
-- Looking for pfm_initialize in pfm
-- Looking for pfm_initialize in pfm - not found
-- Looking for xar_open in xar
-- Looking for xar_open in xar - not found
-- Looking for arc4random
-- Looking for arc4random - not found
-- Looking for backtrace
-- Looking for backtrace - not found
-- Could NOT find Backtrace (missing: Backtrace_LIBRARY Backtrace_INCLUDE_DIR)
-- Performing Test C_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW
-- Performing Test C_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW - Success
-- Looking for _Unwind_Backtrace
-- Looking for _Unwind_Backtrace - not found
-- Looking for getpagesize
-- Looking for getpagesize - not found
-- Looking for sysconf
-- Looking for sysconf - not found
-- Looking for getrusage
-- Looking for getrusage - not found
-- Looking for setrlimit
-- Looking for setrlimit - not found
-- Looking for isatty
-- Looking for isatty - not found
-- Looking for futimens
-- Looking for futimens - not found
-- Looking for futimes
-- Looking for futimes - not found
-- Looking for posix_fallocate
-- Looking for posix_fallocate - not found
-- Looking for sigaltstack
-- Looking for sigaltstack - not found
-- Looking for lseek64
-- Looking for lseek64 - not found
-- Looking for mallctl
-- Looking for mallctl - not found
-- Looking for mallinfo
-- Looking for mallinfo - not found
-- Looking for malloc_zone_statistics
-- Looking for malloc_zone_statistics - not found
-- Looking for getrlimit
-- Looking for getrlimit - not found
-- Looking for posix_spawn
-- Looking for posix_spawn - not found
-- Looking for pread
-- Looking for pread - not found
-- Looking for sbrk
-- Looking for sbrk - not found
-- Looking for strerror
-- Looking for strerror - found
-- Looking for strerror_r
-- Looking for strerror_r - not found
-- Looking for strerror_s
-- Looking for strerror_s - found
-- Looking for setenv
-- Looking for setenv - not found
-- Looking for _chsize_s
-- Looking for _chsize_s - found
-- Looking for _alloca
-- Looking for _alloca - not found
-- Looking for __alloca
-- Looking for __alloca - not found
-- Looking for __chkstk
-- Looking for __chkstk - not found
-- Looking for __chkstk_ms
-- Looking for __chkstk_ms - not found
-- Looking for ___chkstk
-- Looking for ___chkstk - not found
-- Looking for ___chkstk_ms
-- Looking for ___chkstk_ms - not found
-- Looking for __ashldi3
-- Looking for __ashldi3 - not found
-- Looking for __ashrdi3
-- Looking for __ashrdi3 - not found
-- Looking for __divdi3
-- Looking for __divdi3 - not found
-- Looking for __fixdfdi
-- Looking for __fixdfdi - not found
-- Looking for __fixsfdi
-- Looking for __fixsfdi - not found
-- Looking for __floatdidf
-- Looking for __floatdidf - not found
-- Looking for __lshrdi3
-- Looking for __lshrdi3 - not found
-- Looking for __moddi3
-- Looking for __moddi3 - not found
-- Looking for __udivdi3
-- Looking for __udivdi3 - not found
-- Looking for __umoddi3
-- Looking for __umoddi3 - not found
-- Looking for __main
-- Looking for __main - not found
-- Looking for __cmpdi2
-- Looking for __cmpdi2 - not found
-- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC
-- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC - Failed
-- Performing Test HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC
-- Performing Test HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC - Failed
-- Looking for GLIBC
-- Looking for GLIBC - not found
-- Performing Test HAVE_STD_IS_TRIVIALLY_COPYABLE
-- Performing Test HAVE_STD_IS_TRIVIALLY_COPYABLE - Success
-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success
-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Success
-- Performing Test LLVM_HAS_ATOMICS
-- Performing Test LLVM_HAS_ATOMICS - Success
-- Performing Test SUPPORTS_VARIADIC_MACROS_FLAG
-- Performing Test SUPPORTS_VARIADIC_MACROS_FLAG - Success
-- Performing Test SUPPORTS_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS_FLAG
-- Performing Test SUPPORTS_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS_FLAG - Success

I think it has to be covered within https://go.googlesource.com/gollvm/+/refs/heads/master/README.md .

Cross-referencing with #12 (comment) .

Ivan

Configure fails with bash syntax error

Running source configure in bash results in error bash: configure: line 29: syntax error near unexpected token `newline' 'ash: configure: line 29: ` ;;
I installed libbacktrace as part of msys64 while trying to build the DAW application ZRythm

Possibly incorrect binary search usage in dwarf.c

I'm using backtrace_pcinfo() for printing backtraces, and I think I'm hitting an edge case in libbacktrace for some PC values where lldb/gdb work just fine. Unfortunately it's hard to make a small self-contained example out of the binary I have (and I can't attach the binary itself since it's proprietary software) but hopefully the following should be enough to investigate the problem.

For my binary, the problematic PC is 0x24a4265. When libbacktrace tries to find the relevant DWARF unit, dwarf_lookup_pc() bails out early at this line because the bsearch() call from the line above, which uses unit_addrs_search() as a comparison function, returns NULL. I printed out all unit addresses I have along with what the comparison function outputs for them, and here's the relevant part:

[...]
Addr #22782: low = 0x24a3f40, high = 0x24a3f72, unit_addrs_search(pc, addr) = 1, filename = [REDACTED]/1204c9a5db0a366fa0204390af.cpp
Addr #22783: low = 0x24a3f80, high = 0x24a4024, unit_addrs_search(pc, addr) = 1, filename = [REDACTED]/4f8020ed77d34d3bbd744e8cea.cpp
Addr #22784: low = 0x24a4030, high = 0x24a403f, unit_addrs_search(pc, addr) = 1, filename = [REDACTED]/__tests__.exception.reg3.cpp
Addr #22785: low = 0x24a4040, high = 0x24a4166, unit_addrs_search(pc, addr) = 1, filename = [REDACTED]/__vcs_version__.c
Addr #22786: low = 0x24a4170, high = 0x24a4458, unit_addrs_search(pc, addr) = 0, filename = [REDACTED]/exception.pyx.cpp
Addr #22787: low = 0x24a4170, high = 0x24a4170, unit_addrs_search(pc, addr) = 1, filename = [REDACTED]/_1204c9a5db0a366fa0204390af.yasm
Addr #22788: low = 0x24a4170, high = 0x24a4170, unit_addrs_search(pc, addr) = 1, filename = [REDACTED]/_4f8020ed77d34d3bbd744e8cea.yasm
Addr #22789: low = 0x24a4460, high = 0x24a4cea, unit_addrs_search(pc, addr) = -1, filename = [REDACTED]/exception.pyx.cpp
Addr #22790: low = 0x24a4cf0, high = 0x24a66b6, unit_addrs_search(pc, addr) = -1, filename = [REDACTED]/exception.pyx.cpp
Addr #22791: low = 0x24a66c0, high = 0x24a6739, unit_addrs_search(pc, addr) = -1, filename = [REDACTED]/exception.pyx.cpp
[...]

Notice that there are three address ranges matching my PC (#22786, #22787, #22788), and the comparison function outputs 0 for the first one and 1 for the remaining ones (because nested addresses are sorted with unit_addrs_compare(), which makes the smallest range come last).

This seems to contradict the contract for bsearch():

The array shall consist of: all the elements that compare less than, all the elements that compare equal to, and all the elements that compare greater than the key object, in that order.

I can't say for certain because I didn't read the source for bsearch() in glibc, but I think this disrepancy is what makes bsearch() fail even though there are valid address ranges covering the PC. I also didn't read the DWARF standard in its entirety, so I can't say if this DWARF information with overlapping ranges is valid, but it looks legitimate to me (and, again, gdb/lldb correctly find the corresponding line/column/file for this PC).

Implement semver for repository

Considering adding a Conan package to CCI: conan-io/conan-center-index#4262
Could you use tags to implement semver on the repository, please? That would simplify version tracking in CCI.

thank you,this repo helps me a lot!

read.c fails to handle views of more than 2,147,479,552 bytes

On Linux, the read syscall will transfer at most 2,147,479,552 bytes (~2.147 GB). This means that read will return 2,147,479,552 even if the file being read from has more data available.

read.c interprets this condition as the file being too short, resulting in an error:

libbacktrace/read.c

Lines 81 to 86 in 559ab7c

	if ((size_t) got < size)
	{
	error_callback (data, "file too short", 0);
	free (view->base);
	return 0;
	}

If a file's debuginfo sections add up to more than 2,147,479,552 bytes, this will cause a spurious failure:

libbacktrace/elf.c

Lines 3162 to 3165 in 559ab7c

	if (!backtrace_get_view (state, descriptor, min_offset,
	max_offset - min_offset,
	error_callback, data, &debug_view))
	goto fail;

I recognize that it's unusual for a file to have such a large amount of debug info. However, it would be very useful if libbacktrace could handle this case by using multiple read calls, as this issue makes it impossible to generate backtraces for such files.

gccgo-8 crashes in libbacktrace with Bus Error on sparc64

I recently started playing around with the unofficial sparc64 of golang again (from https://github.com/4ad/go) and tried building it using gccgo-8 on Debian unstable on sparc64.

While running gccgo, I ran into a Bus Error which usually means an unaligned access is happening:

glaubitz@kyoto:~/go-1/src$ /usr/bin/go build -o cmd/dist/dist ./cmd/dist
Bus error
glaubitz@kyoto:~/go-1/src$

The backtrace indicates a problem with libbacktrace:

glaubitz@kyoto:~/go-1/src$ gdb --args /usr/bin/go build -o cmd/dist/dist ./cmd/dist
GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/go...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/go build -o cmd/dist/dist ./cmd/dist
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
[New Thread 0xffff800102d01900 (LWP 4116)]
[New Thread 0xffff800103503900 (LWP 4117)]
[New Thread 0xffff800104105900 (LWP 4118)]
[New Thread 0xffff800105107900 (LWP 4119)]
[New Thread 0xffff800105d09900 (LWP 4120)]
[New Thread 0xffff80010650b900 (LWP 4121)]

Thread 1 "go" received signal SIGBUS, Bus error.
elf_add (state=<optimized out>, filename=<optimized out>, descriptor=<optimized out>, base_address=<optimized out>, error_callback=<optimized out>, data=<optimized out>, 
    fileline_fn=<optimized out>, found_sym=<optimized out>, found_dwarf=<optimized out>, exe=<optimized out>, debuginfo=<optimized out>)
    at ../../../src/libbacktrace/elf.c:3151
3151    ../../../src/libbacktrace/elf.c: No such file or directory.
(gdb) bt
#0  elf_add (state=<optimized out>, filename=<optimized out>, descriptor=<optimized out>, base_address=<optimized out>, error_callback=<optimized out>, 
    data=<optimized out>, fileline_fn=<optimized out>, found_sym=<optimized out>, found_dwarf=<optimized out>, exe=<optimized out>, debuginfo=<optimized out>)
    at ../../../src/libbacktrace/elf.c:3151
#1  0xffff8001010b0f5c in elf_add (state=<optimized out>, filename=<optimized out>, descriptor=<optimized out>, base_address=<optimized out>, 
    error_callback=<optimized out>, data=<optimized out>, fileline_fn=<optimized out>, found_sym=<optimized out>, found_dwarf=<optimized out>, exe=<optimized out>, 
    debuginfo=<optimized out>) at ../../../src/libbacktrace/elf.c:2996
#2  0xffff8001010b17a0 in phdr_callback (info=0xffff8001024f8888, size=64, pdata=0xffff8001024f89c0) at ../../../src/libbacktrace/elf.c:3270
#3  0xffff800101c72d40 in __GI___dl_iterate_phdr (callback=0xffff8001010b1730 <phdr_callback>, data=0xffff8001024f89c0) at dl-iteratephdr.c:75
#4  0xffff8001010b19b8 in backtrace_initialize (state=0xffff80010003a000, filename=0x7fefffff735 "/usr/bin/go", descriptor=<optimized out>, 
    error_callback=0xffff800100bf7150 <error_callback>, data=0xffff8001024f9988, fileline_fn=0xffff8001024f8ab8) at ../../../src/libbacktrace/elf.c:3313
#5  0xffff8001010ae1cc in fileline_initialize (state=0xffff80010003a000, error_callback=0xffff800100bf7150 <error_callback>, data=0xffff8001024f9988)
    at ../../../src/libbacktrace/fileline.c:143
#6  0xffff8001010ae2f8 in backtrace_pcinfo (state=0xffff80010003a000, pc=18446603340528710231, callback=0xffff800100bf6e40 <callback>, 
    error_callback=0xffff800100bf7150 <error_callback>, data=0xffff8001024f9988) at ../../../src/libbacktrace/fileline.c:177
#7  0xffff8001010ae82c in unwind (context=0xffff8001024f8d20, vdata=0xffff8001024f98a0) at ../../../src/libbacktrace/backtrace.c:91
#8  0xffff800101ff8c18 in _Unwind_Backtrace () from /lib/sparc64-linux-gnu/libgcc_s.so.1
#9  0xffff8001010ae8b0 in backtrace_full (state=0xffff80010003a000, skip=<optimized out>, callback=0xffff800100bf6e40 <callback>, 
    error_callback=0xffff800100bf7150 <error_callback>, data=0xffff8001024f9988) at ../../../src/libbacktrace/backtrace.c:127
#10 0xffff800100bf7258 in runtime_callers (skip=<optimized out>, locbuf=0xffff8001024f9e40, m=<optimized out>, keep_thunks=<optimized out>)
    at ../../../src/libgo/runtime/go-callers.c:207
#11 0xffff800100f7f2c0 in runtime.callers (skip=<optimized out>, locbuf=...) at ../../../src/libgo/go/runtime/traceback_gccgo.go:56
#12 0xffff800100fb1ce8 in runtime.mProf_Malloc (size=80, p=<optimized out>) at ../../../src/libgo/go/runtime/mprof.go:342
#13 runtime.profilealloc (mp=0xffff800101949f30 <runtime.m0>, size=80, x=0xc42021e690) at ../../../src/libgo/go/runtime/malloc.go:899
#14 runtime.mallocgc (size=<optimized out>, typ=<optimized out>, needzero=<optimized out>) at ../../../src/libgo/go/runtime/malloc.go:815
#15 0xffff800100fb64ec in runtime.growslice (et=0xffff8001015b48c8 <go_token.Position..d>, old=..., cap=2) at ../../../src/libgo/go/runtime/slice.go:183
#16 0xffff800100d3833c in go_build.Context.Import (ctxt=<optimized out>, path=..., srcDir=..., mode=<optimized out>) at ../../../src/libgo/go/go/build/build.go:872
#17 0x000001000008a4e0 in ?? ()
#18 0x000001000008f8b0 in ?? ()
#19 0x00000100000952b0 in ?? ()
#20 0x00000100000956b8 in ?? ()
#21 0x00000100000dd390 in ?? ()
#22 0x000001000006670c in main.main ()
(gdb)

A sparc64 porterbox running Linux is available in the gcc compile farm, see: https://gcc.gnu.org/wiki/CompileFarm

some issues & fixes

I can't really sign the CLA right now easily, but I can give you a list of issues I encountered & had to fix:

• the typedef of backtrace_error_callback shouldn't use "errnum" as that may be a macro in some windows environments
• there's another corruption bug with size_t just like the rust folks reported, with fhdr_off in pecoff.c
• what you read as virtual_size in pecoff really seems to be physical_addr?

"edtest" and "ttest" failures

test1: [0]: missing file name or function name
FAIL: backtrace_full alloc stress
FAIL: edtest
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
FAIL: threaded backtrace_full noinline
FAIL: ttest

libbacktrace SEGV with compressed debug sections (-gz)

Libbacktrace does not seem to understand compressed debug sections.
Compressed debug sections are generated with the -gz flag.
Instead the program hits a SEGV while generating the backtrace. This seems to be another bug.
But I don't know if libbacktrace should be able to deal with faulty debug info.

libbacktrace skip parameter can skip several inlined functions

On Ubuntu 16.04, when I compile a program with "-g" or "-ggdb", for 32-bit mode programs, libbacktrace can infer file and line numbers. For 64-bit mode programs, this does not work.

How to reproduce: Compile this program in 64-bit mode.
backtrace-via-libbacktrace.c.gz

$ gcc -g -O2 -lbacktrace
$ ./a.out
0x7f7b8e38e83f ???
        ???:0
0x401178 ???
        ???:0
0xffffffffffffffff ???
        ???:0

and

$ gcc -ggdb -O2 -lbacktrace
$ ./a.out
0x7f63a997183f ???
        ???:0
0x401178 ???
        ???:0
0xffffffffffffffff ???
        ???:0

gcc is version 5.4.0. gdb does understand the debug info.

How to create the libbacktrace.so from the available Makefile ?

Hi, I was experimenting one of my C program to print its backtrace on crash. For that I was landed here from the google search and I wish to use this libbacktrace library. I was compiled the code and seeing only the archive files and not seeing any .so file.

libtool: link: ranlib .libs/libbacktrace.a
libtool: link: ( cd ".libs" && rm -f "libbacktrace.la" && ln -s "../libbacktrace.la" "libbacktrace.la" )

In my tool, I want to use the libbacktrace as SO file. So, could you please guide me to generate the SO file to make my work complete.

I was refered the Makefile.am and searched the TARGET for SO creation but not found.

Memory leak when using libbacktrace 'backtrace_full' repeatedly

Our application makes use of libbacktrace in order to present meaningful backtraces when certain 'errors' occur in our code. Unlike in the case of a crash report the application is allowed to continue in many cases, which can lead to repeated calls to backtrace_full().

We have observed that the memory allocated by our program increases with time and I have traced back this memory increase to the use of mmap in libbacktrace. If I understand the code correctly then the executable and its dependent libraries are mmaped into memory and parsed for DWARF debug information. But I suspect that the mmaped memory is not properly unmapped in all the cases.

I have run our code within 'valgrind --tool=massif --pages-as-heap=yes' (which means that virtual memory is measured, but I also see a similar increase in RSS) and visualized the memory consumption with massif-visualizer. I attach two figures: The memory growth as a function of time and the callgraph for the peak snapshot.

Hopefully this will help to debug the issue.

callgraph.png.gz

Thanks for your help

Installation problem

After commit 17f687d only header files are installed by make install, but not the compiled library itself. Tested on Debian Sid, gcc version: 7.2.0, make version: 4.1

llvm scan-build NULL ptr in lookup_abbrev() passed to bsearch()

After updating the scan-build checks for our project, which uses libbacktrace, the anaylzer reports that bsearch() gets an invalid NULL ptr. I can't upload the html file here, so please fine it here

http://www.aakef.fastmail.fm/linux/libbacktrace_dwarf.c.html

For now I have added this patch to our code, as I don't have time to investigate more in details.

index 55b8d7dc2a..ec8d3bec6a 100644
--- a/libbacktrace/dwarf.c
+++ b/libbacktrace/dwarf.c
@@ -1167,6 +1167,13 @@ lookup_abbrev (struct abbrevs *abbrevs, uint64_t code,
   /* Otherwise we have to search.  */
   memset (&key, 0, sizeof key);
   key.code = code;
+
+  if (!abbrevs->abbrevs)
+  { /* Fixes scan-build warning */
+      error_callback (data, "NULL ptr abbrevs", 0);
+      return NULL;
+  }
+
   p = bsearch (&key, abbrevs->abbrevs, abbrevs->num_abbrevs,
               sizeof (struct abbrev), abbrev_compare);
   if (p == NULL)

libbacktrace allocation is sometimes very slow

originally here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68239

affects rustc as mentioned here: rust-lang/rust#38984

Basically, if you have Rust via rustup, you can test like this(assuming shell is bash):

$ time RUST_BACKTRACE=1 rustc -vv
error: Option 'verbose' given more than once.


real	0m0.929s
user	0m0.888s
sys	0m0.037s

$ time RUST_BACKTRACE=0 rustc -vv
error: Option 'verbose' given more than once.


real	0m0.161s
user	0m0.139s
sys	0m0.023s

There's a time difference of almost 0.8s, which isn't much, but will be very noticeable(goes up to like 40 seconds?) if rust is compiled with debug-info.

I'm not sure what could be done, but there's a somewhat in-depth explanation here rust-lang/rust#37477 (comment)

Cheers!

backtrace deadlocks when jemalloc heap profiling is enabled

Basically the same bug as libunwind/libunwind#16 -

The implementation of dl_iterate_phdr in glibc both takes locks, and allocates memory. People hit this sporadically in production.
Barring a fix in glibc, the best fix is probably an optionally linked library that will override dlopen, dlclose, and dl_iterate_phdr with a lock-free and non-mallocing cache.

As a hacky workaround I think we can disable jemalloc's heap profiling with mallctl while calling dl_iterate_phdr within libbacktrace, but that would still leave problems for other malloc or heap profiling implementations.

Supplying dependency for missing dlfcn.h, on Windows 10: review of dlfcn-win32, as a candidate, for a dependency (or a merger)

Hello again.

So, I was checking all missing headers, while compiling https://go.googlesource.com/gollvm and https://github.com/ianlancetaylor/libbacktrace .

So while I was checking

-- Looking for dlfcn.h
-- Looking for dlfcn.h - not found

I found that such a project exists:
https://github.com/dlfcn-win32/dlfcn-win32
. It seems to be oriented against CMake - so it could be vibrant with #12.

@TimothyGu , @pali , @ramiropolla , @traversaro - please follow up.
Also hence #12

Ivan

Remove generated files from git

The git repository contains many files that are generated and shouldn't be stored in git.

configure, aclocal.m4, all of config/, and so on.

error: incomplete definition of type 'struct dl_phdr_info'

get this build error from Debian:

clang -cc1 version 10.0.1 based upon LLVM 10.0.1 default target x86_64-pc-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
backtrace
 /usr/local/include
 /usr/lib/llvm-10/lib/clang/10.0.1/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
backtrace/elf.c:4812:23: warning: declaration of 'struct dl_phdr_info' will not be visible outside of this function [-Wvisibility]
phdr_callback (struct dl_phdr_info *info, size_t size ATTRIBUTE_UNUSED,
                      ^
backtrace/elf.c:4825:11: error: incomplete definition of type 'struct dl_phdr_info'
  if (info->dlpi_name == NULL || info->dlpi_name[0] == '\0')
      ~~~~^
backtrace/elf.c:4812:23: note: forward declaration of 'struct dl_phdr_info'
phdr_callback (struct dl_phdr_info *info, size_t size ATTRIBUTE_UNUSED,
                      ^
backtrace/elf.c:4825:38: error: incomplete definition of type 'struct dl_phdr_info'
  if (info->dlpi_name == NULL || info->dlpi_name[0] == '\0')
                                 ~~~~^
backtrace/elf.c:4812:23: note: forward declaration of 'struct dl_phdr_info'
phdr_callback (struct dl_phdr_info *info, size_t size ATTRIBUTE_UNUSED,
                      ^
backtrace/elf.c:4841:22: error: incomplete definition of type 'struct dl_phdr_info'
      filename = info->dlpi_name;
                 ~~~~^
backtrace/elf.c:4812:23: note: forward declaration of 'struct dl_phdr_info'
phdr_callback (struct dl_phdr_info *info, size_t size ATTRIBUTE_UNUSED,
                      ^
backtrace/elf.c:4842:40: error: incomplete definition of type 'struct dl_phdr_info'
      descriptor = backtrace_open (info->dlpi_name, pd->error_callback,
                                   ~~~~^
backtrace/elf.c:4812:23: note: forward declaration of 'struct dl_phdr_info'
phdr_callback (struct dl_phdr_info *info, size_t size ATTRIBUTE_UNUSED,
                      ^
backtrace/elf.c:4848:62: error: incomplete definition of type 'struct dl_phdr_info'
  if (elf_add (pd->state, filename, descriptor, NULL, 0, info->dlpi_addr,
                                                         ~~~~^
backtrace/elf.c:4812:23: note: forward declaration of 'struct dl_phdr_info'
phdr_callback (struct dl_phdr_info *info, size_t size ATTRIBUTE_UNUSED,
                      ^
backtrace/elf.c:4892:3: warning: implicit declaration of function 'dl_iterate_phdr' is invalid in C99 [-Wimplicit-function-declaration]
  dl_iterate_phdr (phdr_callback, (void *) &pd);
  ^
2 warnings and 5 errors generated.

Suboptimal information when no debug info is available

When no debug info is available, the library just prints question marks. It could use the /proc/self/maps file (on Linux) to at least print the binary object file in which the code resides.

How to reproduce: Compile this file
backtrace-via-libbacktrace.c.gz
on Ubuntu 16.04 in 32-bit mode:

$ gcc -m32 -g -O2 backtrace-via-libbacktrace.c -lbacktrace
$ ./a.out

It prints

08048000-0805a000 r-xp 00000000 08:06 5785797                            /home/bruno/a.out
0805a000-0805b000 r--p 00011000 08:06 5785797                            /home/bruno/a.out
0805b000-0805c000 rw-p 00012000 08:06 5785797                            /home/bruno/a.out
f75d2000-f75d3000 rw-p 00000000 00:00 0 
f75d3000-f7783000 r-xp 00000000 08:06 263678                             /lib/i386-linux-gnu/libc-2.23.so
f7783000-f7784000 ---p 001b0000 08:06 263678                             /lib/i386-linux-gnu/libc-2.23.so
f7784000-f7786000 r--p 001b0000 08:06 263678                             /lib/i386-linux-gnu/libc-2.23.so
f7786000-f7787000 rw-p 001b2000 08:06 263678                             /lib/i386-linux-gnu/libc-2.23.so
f7787000-f778a000 rw-p 00000000 00:00 0 
f778a000-f77a6000 r-xp 00000000 08:06 272038                             /lib/i386-linux-gnu/libgcc_s.so.1
f77a6000-f77a7000 rw-p 0001b000 08:06 272038                             /lib/i386-linux-gnu/libgcc_s.so.1
f77d5000-f77d6000 rw-p 00000000 00:00 0 
f77d6000-f77d8000 r--p 00000000 00:00 0                                  [vvar]
f77d8000-f77d9000 r-xp 00000000 00:00 0                                  [vdso]
f77d9000-f77fc000 r-xp 00000000 08:06 263691                             /lib/i386-linux-gnu/ld-2.23.so
f77fc000-f77fd000 r--p 00022000 08:06 263691                             /lib/i386-linux-gnu/ld-2.23.so
f77fd000-f77fe000 rw-p 00023000 08:06 263691                             /lib/i386-linux-gnu/ld-2.23.so
fff07000-fff29000 rw-p 00000000 00:00 0                                  [stack]
0x8048e55 dummy_function
        /home/bruno/backtrace-via-libbacktrace.c:18
0x8048e55 main
        /home/bruno/backtrace-via-libbacktrace.c:28
0xf75eb646 ???
        ???:0
0x8048e96 ???
        ???:0

From the maps file, it would be evident that 0xf75eb646 is an address in /lib/i386-linux-gnu/libc-2.23.so, and 0x8048e96 is an address in /home/bruno/a.out.

mingw issue with executable path

Getting the following error from callback after backtrace_full:

static void
ErrorCallback(void* data, const char* message, int err)

executable file is not COFF (0)
failed to read executable information (-1)

Then it it's an infinite loop of last error. Under Linux it runs fine.

Environment:

Statically linked executable
ExceptionTest.exe: PE32+ executable (console) x86-64, for MS Windows
OS:Ubuntu/Wine
MXE static compiler

Any clues?

backtrace returns mix of absolute and relative paths; how to force absolute paths?

after investigation, this is the root cause for status-im/nim-libbacktrace#11

this library does not preserve absolute paths in backtrace if the input file is rooted under $PWD/anydir/

it does preserve absolute paths if the input file is under $PWD/foo.c or not rooted under $PWD (eg /other/foo.c)

this is a problem for several reasons eg

• when a script changes directory and then invokes compilation
• when different files are compiled in different directories
• when users expect absolute paths

note that in all cases, I'm invoking clang with absolute paths (and dwarfdump correctly shows absolute paths)

to reproduce

git clone https://github.com/ianlancetaylor/libbacktrace
cd libbacktrace
./configure
apply the patch [1] which simply adds a call to backtrace_print
mkdir sub
cp mtest.c sub # note that, as noted above, things work if we use $(pwd)/mtest.c, but not $(pwd)/sub/mtest.c
DESTDIR=/tmp/d15c make install

• clang -o /tmp/z01 -L/tmp/d15c/usr/local/lib -g -I. $(pwd)/sub/mtest.c testlib.c -Wl,-lbacktrace
• /tmp/z01

output

D20210405T202237
0x103c24de8 f3
sub/mtest.c:112
0x103c24d17 f2
sub/mtest.c:94
0x103c24ccd test1
sub/mtest.c:88
0x103c24c8e main
sub/mtest.c:404
PASS: backtrace_full noinline
PASS: backtrace_simple noinline
test5: unexpected syminfo name got _dyld_private expected global
FAIL: backtrace_syminfo variable

expected output

$PWD/sub/mtest.c instead of sub/mtest.c, where $PWD is the current dir

maybe related

#26

patch [1]

diff --git a/mtest.c b/mtest.c
index 7e0189a..f3a682b 100644
--- a/mtest.c
+++ b/mtest.c
@@ -108,6 +108,8 @@ f3 (int f1line __attribute__ ((unused)), int f2line __attribute__ ((unused)))
   data.failed = 0;

   i = backtrace_full (state, 0, callback_mtest, error_callback_one, &data);
+  printf("D20210405T202237\n");
+  backtrace_print (state, 0, stdout);

   if (i != 0)
     {

note 1

i'm on osx, if that matters

note 2

after investigating, in dwarf.c:

  hdr->filenames[0] = u->filename;
  printf("D20210405T183857.2 %s\n", u->filename); // would print absolute paths

  i = 1;
  while (*hdr_buf->buf != '\0')
    {
      printf("ok1\n");
      const char *filename;
      uint64_t dir_index;

      if (hdr_buf->reported_underflow)
	return 0;

      filename = read_string (hdr_buf);
      printf("D20210405T183857.3 %s\n", filename); // would not print absolute paths
      if (filename == NULL)
	return 0;
      dir_index = read_uleb128 (hdr_buf);

note 3

DW_AT_comp_dir is probably incorrectly used (see comp_dir)
even if internal DWARF representation uses relative paths relative to compilation dir for compression, backtrace API should "decompress" those into absolute paths in a given compilation unit, at very least as an option.

The caller of backtrace API doesn't have access to DW_AT_comp_dir, in particular different compilation units could have their own DW_AT_comp_dir.

ntoe 4

the code in read_v2_paths seems relevant, eg:

	  memcpy (s + dir_len + 1, filename, filename_len + 1);

misc links

• PR77895: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path - Patchwork

No backtrace with Mingw64

No backtrace is generated when built with mingw64 under msys2(Windows 10) or MXE(Ubuntu). Several library tests fail. Only tested 64 bit static mingw GCC.

btest fails:

$ ./btest.exe
FAIL: backtrace_full noinline
FAIL: backtrace_full inline
FAIL: backtrace_simple noinline
FAIL: backtrace_simple inline
test1: [0]: missing file name or function name
test2: [0]: missing file name or function name
test3: [0]: missing file name or function name
test3: [0]: NULL syminfo name
test3: [1]: NULL syminfo name
test3: [2]: NULL syminfo name
test4: [0]: missing file name or function name

Consider installing a pkg-config file

We got this request downstream for a .pc file: msys2/MINGW-packages#7670

File names being empty with version 5 .debug_line

In version 5 .debug_line sections, a file name table starts with number 0. In the current code, however, filename is set to an empty string when the entry number is equal to 0.

A proposed modification:

--- libbacktrace.orig/dwarf.c
+++ libbacktrace/dwarf.c
@@ -3182,7 +3182,7 @@ read_line_program (struct backtrace_stat
 		uint64_t fileno;
 
 		fileno = read_uleb128 (line_buf);
-		if (fileno == 0)
+		if (fileno == 0 && hdr->version < 5)
 		  filename = "";
 		else
 		  {

Split DWARF support

Does libbacktrace have any support for -gsplit-dwarf?

I don't know about the DWARF5 flavor, but with the GNU flavor there's a dwp tool that functions like dsymutil to generate a file.dwp containing the linked debug info from a -gsplit-dwarf build:
https://gcc.gnu.org/wiki/DebugFissionDWP

make[1]: don't know how to make elf_32.lo

$ make check
make libbacktrace_alloc.la libbacktrace_noformat.la libbacktrace_instrumented_alloc.la allocfail test_elf_32 test_elf_64 test_macho test_xcoff_32 test_xcoff_64 test_pecoff test_unknown unittest unittest_alloc btest btest_lto btest_alloc stest stest_alloc ztest ztest_alloc edtest edtest_alloc ttest ttest_alloc dwarf5 dwarf5_alloc mtest xztest xztest_alloc
libbacktrace_alloc.la' is up to date. libbacktrace_noformat.la' is up to date.
libbacktrace_instrumented_alloc.la' is up to date. allocfail' is up to date.
make[1]: don't know how to make elf_32.lo. Stop

make[1]: stopped in /usr/home/oceanfish81/libbacktrace

$ uname -a
FreeBSD gollvm.build.server 13.0-CURRENT FreeBSD 13.0-CURRENT #0 b9403d7aae8-c254071(main): Thu Oct 29 08:06:03 UTC 2020 [email protected]:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

https://www.freshports.org/devel/libepoll-shim was installed.

As for the main source code base - end-user API was compiled without errors.

Use of uninitialised value in libbacktrace/pecoff.c

In coff_add(), str_size is declared as a size_t, but if there is a symbol table, only 4 bytes of it are initialised:

memcpy (&str_size, syms_view.data + syms_size, 4);

str_size should probably be declared as a uint32_t.

The bug at rust-lang/rust#28447 was caused by this.
It was fixed in the Rust local copy of libbacktrace: rust-lang/rust@55e2b7e

This was reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69314

Add support for CMake

CMake is one of the most popular portable build systems for C++. Adding support for it to libbacktrace would greatly simplify integration with other projects and increase the popularity of this library.

There is a standalone fork of libbacktrace with CMake support, but it hasn't been updated in a long time. - https://github.com/ErwanLegrand/libbacktrace. Perhaps it could be used as an inspiration for this project.

Fails to build with autoconf 2.71

> autoreconf -vfi
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I config
configure.ac:33: error: Please use exactly Autoconf 2.69 instead of 2.71.
config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:33: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal-1.15: error: echo failed with exit status: 1
autoreconf: error: aclocal failed with exit status: 1

If that's not supported feel free to close.

elf_add freeing strtab_view in fail, even though it shouldn't

Hey,
I've stumbled over a crash in servo, which is using a rust wrapper around this library.
You can see my findings here, rust-lang/backtrace-rs#267, but a short description is: elf.c:elf_add#2965 claims, that "we hold on to the string table permanently.", which is only true until a elf.c:elf_add:fail#3197, which is caused by elf.c:elf_add#3071

Now I don't know if it's "okay" for L3071 to fail, like this expected, then Line 3197 is just wrong.
If this is a more critical fault or releasing the symnames there is required, then the changes made to the state (symdata) have to be rolled back, so noone is relying on them as the error is not propagated back, but skipped.

Thanks in Advance :)

no symbol, filename, lineno on macOS 10.15

I try use libbacktrace on my project. for linux it work very well, but macOS can not find symbol.

I build with clang option -gdwarf-4, I can confirm the object file include dwarf debug data by run dwarfdump test.o

but the final binary has no such section anymore:

dwarfdump ./test
.debug_info contents:

backtrace_full_callback get NULL for filename, lineno, fn.

atos is able to get the symbol and line number.

What to do to make it return filename and lineno ? Is there some option I can pass to ld to generate linux like bianry with .debug_info section ?

std::exception

Hello,

I'm already using the library for custom C++ exception but I'd like to add backtrace capability for STL exceptions. I found an approach that might work but I'm not sure how to integrate it with libbacktrace. The idea is to replace __cxa_throw like so:

  void __cxa_throw(void* ex, void* info, void (*dest)(void*))
  {
    //demangle and store backtrace here
    .. demangle(reinterpret_cast<const std::type_info*>(info)->name());
    ...backtrace(...);

    static void (*const rethrow)(void*, void*, void (*)(void*)) __attribute__((noreturn)) = (void (*)(void*, void*, void (*)(void*)))dlsym(RTLD_NEXT, "__cxa_throw");
    rethrow(ex, info, dest);
  }

This works by itself but I'd like to tie it with library. Should I just call backtrace_full from within the new throw handler? Are there any caveats? Perhaps there is a better way?

Thanks!

Set license also in github metadata

The project description makes it clear that is BSD and the LICENSE file is in place, but github metadata still reports the license of the project as "other". I think that needs to be set manually.

how to get stack addresses in libbacktrace API or get symbolicated backtrace from stack addresses

• how to get stack addresses in libbacktrace API? eg same addresses as generated by backtrace (https://linux.die.net/man/3/backtrace)

• example use case: see timotheecour/Nim#49 (comment) but there could be more

Backtrace for shared libraries: difference between elf and pecoff

In my use case, I don't care about symbols/debug info in the main executable, only for the shared libraries loaded during run time. Everything works fine on Linux x64, which I believe uses elf.c. On MSYS, with pecoff.c, I only get symbols/debug info for the module that I pass as the filename argument to backtrace_create_state(). (I can pass the path to a shared library to backtrace_create_state(), and the file+line information is extracted from there but not from the other shared libraries loaded from the process.)

Could you please shed some light on the difference in the observed behavior? Does elf.c iterate over all loaded libraries, and pecoff.c not? What's the best way to resolve this?