On Apr 24, 3:10 pm, kemofish wrote:
> I'm guessing the "stack" tool uses addr2line as described by Jorge
> below but it goes through the logcat output, finds the crash log
> entries, and does the addr2line conversion.
>
> Does "stack" exist or is it an Android myth???
vendor/google/tools/stack e
I've heard of an Android tool called "stack" which helps analyze
crashes seen in logs.
Supposedly, this tool is located in /android/tools/stack but I
don't see it.
I believe its used as follows:
cd /android
adb logcat -d > log.txt
tools/stack log.txt > results.txt
I'm guessing the "stack" tool u
To figure out this crash, you will need to use the addr2line tool
manually.
1) Find the path to the addr2line enter this command in the build env:
~/mydroid$ find . -name *addr2line
2) Find the location of the symbol directory enter this command in the
build env:
~/mydroid$ find . -name li
Hi
While trying to debug native C libraries, upon receiving a SIGSEGV,
the core dump thrown does not map address values to symbols as seen in
DDMS. As mentioned above this is happening due to stripping of
binaries.
How can we prevent such stripping in Android or obtain detailed stack
trace despi
Hi
While trying to debug native C libraries, upon receiving a SIGSEGV,
the core dump thrown does not map address values to symbols as seen in
DDMS. As mentioned above this is happening due to stripping of
binaries.
How can we prevent such stripping in Android or obtain detailed stack
trace despi
On Feb 12, 1:59 am, "click...@gmail.com" wrote:
> I am looking for little more informations rather than Hex values.
> Like the backtrace feature where the stack hex values is mapped to the
> function names and function names are visible.
The device can't show these, because the symbols are strip
6 matches
Mail list logo