On Jan 21, 10:18 am, Robert Green <[email protected]> wrote: > Is there any way to track down the function segfaulting using those > memory addresses?
I have half an answer, which is more than I used to have. :-) build/tools/adbs is a front-end shell script that watches for native crashes in logcat and converts the addresses to symbols for you. This only works if you have copies of the libraries with symbols, so it's not much help with the SDK. But if you're building the full Android source, you'll have what you need. And it's a fully-functional example of how addr2line is applied. http://android.git.kernel.org/?p=platform/build.git;a=blob_plain;f=tools/adbs;hb=HEAD I can get symbols for DRC83 kila-user, but it doesn't say much: Stack Trace: RELADDR FUNCTION FILE:LINE 00004408 android_atomic_dec /usr/local/google/buildbot/ repo_clients/git_donut-release/system/core/libcutils/atomic-android- arm.S:115 v------> ?? ??:0 ad32d6a3 (unknown) ??:0 Unfortunately the atomic ops, written in assembly, lack the assembler pseudo-ops required to appease the stack unroller. As a result it can't figure out who the next caller in the stack is. (This will be corrected in a future release.) It's crashing at a near-null address in the atomic ops, suggesting somebody is passing a null pointer around when they shouldn't be. How easy is this to replicate?
-- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
