| 6292bbbc3f678648fb5a1ec8222d33f6a5bb992a |
|
02-Mar-2016 |
Christopher Ferris <cferris@google.com> |
Ignore compressed sections on local unwinds.
When doing local unwinds, attempts to work on compressed sections is
not necessary since this is only called from ART. ART already dumps the
java stacks and that's the only compressed sections that will be used.
It turns out that trying to process the compressed section in local unwinds
can cause problems since the uncompressed section can be large, which
means suddenly a lot more memory being consumed by the process. It also
takes extra time to complete the unwind, which can cause problems when
an ANR occurs, which might trigger a cascade of ANRs since the unwind
is so cpu intensive.
Bug: 27391690
Change-Id: I98be5754cc4de4071616db334dc0c9862d3a2504
/external/libunwind/src/os-common.c
|
| 1aaf3b45edb306600589f5a3969d7a7004798823 |
|
10-Feb-2016 |
Christopher Ferris <cferris@google.com> |
Make sure that elf_image structure is copied.
A previous change modified the code so that a pointer to the elf_image
structure from the map data was returned instead of copied. This can
cause a race condition when doing local unwinds if the map needs to be
rebuilt. One thread might have a pointer to a freed data structure.
To fix this, make sure that the elf_image is always copied when the
contents are going to be used.
In addition, remove the map pointer in the mapped data because it could
also be stale when a local unwind causes a map rebuild. Add a big comment
in front of the elf_image structure to explain this so it won't happen
again.
Bug: 27123610
(cherry picked from commit 2c0f916cac65c1a14e9a917452a430c490ff9620)
Change-Id: I162b396c24923fe9e3d774488b221244d822096c
/external/libunwind/src/os-common.c
|
| 06e604a3cc470460af1ff7a179ccc7e51bd98072 |
|
02-Feb-2016 |
David Srbecky <dsrbecky@google.com> |
Cache decompressed .gnu_debugdata sections.
Change-Id: Ia7260642e7567acb72b1cce38016ce063acbf521
/external/libunwind/src/os-common.c
|
| b025c42a5335e46ab117eb5e55822483ae1cf1b4 |
|
20-Aug-2015 |
Christopher Ferris <cferris@google.com> |
Force memory unwinds to use a zero map offset.
The dlopen of a shared library from an apk results in huge non-zero
map offsets. This can cause failures due to the checks in the code
of the map offset against the elf data.
Currently, unwinds only work through a map that is in the process's
memory, so this will cover any attempt to unwind through a shared
library that was loaded from an apk.
Bug: 23348999
Change-Id: I3f9d95262be1b17a8adb7e1e4ef0196dabe77d51
/external/libunwind/src/os-common.c
|
| cdf0d03deb539dd92d5752d237127b74406c631f |
|
04-May-2015 |
Christopher Ferris <cferris@google.com> |
Implement method to read elf data from memory.
I rewrote the entirety of elfxx.h/elfxx.c to support this.
For the rewrite, I modified the way that the symbol tables are searched.
The searched every single entry in the symbol table, and all symbol tables.
The new method finds the first entry that actually has a name and stops.
I also added some quick checks to make sure that a malformed elf would
not cause a crash when reading the symbol names from the symbol tables.
I had to implement the functionality of dwarf_find_unwind_table to handle
reading from memory, instead of from a file. I didn't implement debug frame
support since that likelihood of that appearing in memory seems low.
I also modified the dwarf_find_unwind_table to remove an abort and just
fail if that particular path is encountered. In addition, I added a quick
check to make sure that a malformed dynamic section doesn't cause a crash.
Bug: 19517541
(cherry picked from commit ae38b20031a02d3f6f56a8315c1f097ae5293c56)
Change-Id: I4e6542d15effdbb6f256f64d89bd1c328da49e9b
/external/libunwind/src/os-common.c
|
| e64e77857aae2ed6c7e6a0e773bede5b877cabb3 |
|
08-Apr-2014 |
Christopher Ferris <cferris@google.com> |
Fix local_get_elf_image prototype.
Change-Id: I3fb0de34ac0447e25b0c0368f76044b4bfc834ba
/external/libunwind/src/os-common.c
|
| f4a8df5f4f338f1a12c25213227e98b34b42447f |
|
08-Mar-2014 |
Christopher Ferris <cferris@google.com> |
Fix maps caching for local processes.
It is possible for the map to change while running libunwind. For example,
if lots of threads are doing local unwinds at the same time. Allow the
cached map to regenerate when it detects this case.
Included in this change is a refactor of all of the os code so that it can
also be used to do caching. This is a prelude to being able to attempt to
push the code upstream.
Also, this moves the code back closer to the original upstream code.
Hopefully, this will allow me to upstream all of these changes.
Change-Id: Ia219fa61e16e36416133bc95b1dd2161bd5b8ff7
/external/libunwind/src/os-common.c
|