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

Sentry-native is updated #9

Merged
merged 51 commits into from
Oct 25, 2021
Merged

Conversation

yucelalbar
Copy link
Collaborator

No description provided.

torarnv and others added 30 commits April 9, 2021 08:41
It now works in memory, without requiring to mmap the libraries again,
which should make it work correctly on android when loading libraries
directly from apk or appbundle files.

The new code will keep track of readable memory maps and will
translate read requests based on the offset of those memory maps,
making sure that we actually can read whatever we are trying to read.
It looks like cmake is broken and builds ALL the targets when the parallel option is specified first, lol
Adds:
* `sentry_value_new_exception`
* `sentry_value_new_thread`
* `sentry_value_new_stacktrace`
* `sentry_event_add_exception`
* `sentry_event_add_thread`

Deprecates `sentry_event_value_add_stacktrace`
This replaces the former `sentry_shutdown`, which is being forwarded.
This should allow building on older macOS versions as well as
running on older versions by fixing the usage of __builtin_available,
and adding a different clock source for older macOS versions.
…#548)

Previously, the `inproc` and `crashpad` (on linux) backends didn’t correctly reset their signal handlers when doing `reinstall_backend` (or multiple `init` calls for that matter).
This has led to an infinite loop generating crashes.

The fix now correctly unregisters the inproc/crashpad signal handlers, and adds an integration test using `reinstall_backend` to make sure we do not end up in an infinite loop.

Co-authored-by: Mischa Alff <[email protected]>
This fixes compilation of breakpad for 32-bit systems
We have received a report that the `sentry_get_modules_list` on mac can deadlock
when other code concurrently does a `dlopen` and thus invokes the `add_image`
callback from a different thread.

We shorten/split the locked blocks in order to avoid holding a lock in the
`get_modules` function whenever the `add_image` function is being invoked possibly
from other threads.
According to some docs, JVM/JNI stacks on Android can be as small as
32K, and our own sigaltstack is not much larger with 64K.
Make sure to avoid large stack allocations as much as possible.

We have especially seen the literal content of `/proc/self/maps` as well
as formatted addresses inside corrupted release/environment attributes,
which might point to overflows that write into a previously allocated
release/environment string.
getsentry-bot and others added 21 commits June 24, 2021 09:23
This is using the `process_vm_read` call to safely poke at random memory. It also makes sure to shim the libc provided call with a direct syscall for older Android devices.
@yucelalbar yucelalbar merged commit ec015d5 into timedoctor Oct 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.