It happens every time.
On Jan 21, 2:35 pm, fadden <[email protected]> wrote: > 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=to... > > 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
