Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added an option to use libc backtrace function from execinfo.h #70

merged 3 commits into from Jan 11, 2019


None yet
3 participants
Copy link

ivanarh commented Jan 10, 2019

  • Set on iOS 32-bit platforms. See #46

ivanarh added some commits Jan 7, 2019

Added an ability to use libc backtrace() function (from execinfo.h) i…
…nstead of _Unwind_Backtrace on Unix-like systems. Useful on iOS 32-bit ARM where _Unwind_Backtrace symbol is undefined.

This comment has been minimized.

Copy link

coveralls commented Jan 10, 2019

Coverage Status

Coverage increased (+0.02%) to 90.265% when pulling 839a1a1 on ivanarh:use_execinfo_backtrace into d708d17 on boostorg:develop.

@apolukhin apolukhin merged commit 158a59a into boostorg:develop Jan 11, 2019

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
continuous-integration/travis-ci/pr The Travis CI build passed
coverage/coveralls Coverage increased (+0.02%) to 90.265%

This comment has been minimized.

Copy link

apolukhin commented Jan 11, 2019

Many thanks for the PR!

I'm worried about async signal safety of backtrace() on Ios. Are there any guarantees?


This comment has been minimized.

Copy link
Contributor Author

ivanarh commented Jan 12, 2019

I'm worried about async signal safety of backtrace() on Ios. Are there any guarantees?

It may depend on libc implementation and (or) on platform. For example, let's take a look to it's source in glibc:
It's a simple wrapper around _Unwind_Backtrace. But it's loaded by dlopen/dlsym calls. So if backtrace() function is called for a first time from signal handler it's may be unsafe. But a workaround may be used: backtrace() should be called once before any signal handlers.

What about apple libc implementation, it's completely different:
It relies on Apple ABI where an old frame pointer is saved to the stack. All it does is jumping from current frame pointer to previous in a cycle. But couple of external calls exist:

pthread_t self = pthread_self();
void *stacktop = pthread_get_stackaddr_np(self);
void *stackbot = stacktop - pthread_get_stacksize_np(self);

pthread_self is signal safe, pthread_get_stackaddr_np is not properly documented.
I see some explicit locks in its source code:

void *
pthread_get_stackaddr_np(pthread_t t)
	int ret;
	void *addr = NULL;

	if (t == NULL) {
		return (void *)(uintptr_t)ESRCH; // XXX bug?
	// since the main thread will not get de-allocated from underneath us
	if (t == pthread_self() || t == &_thread) {
		return t->stackaddr;


So it may be unsafe. But this code isn't reached when we work with a current thread.

Therefore, signal safety of backtrace function is an arguable question.

@ivanarh ivanarh deleted the ivanarh:use_execinfo_backtrace branch Jan 12, 2019

apolukhin added a commit that referenced this pull request Jan 12, 2019


This comment has been minimized.

Copy link

apolukhin commented Jan 12, 2019

Looks safe to me. Many thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.