Nesta seção, focamos no androidQ e analisamos uma função para depuração no android, que é a lápide, comumente conhecida como "lápide". Na vida real, a lápide é geralmente preparada para os mortos, enquanto a "lápide" no sistema android é preparada para o processo.
Por que o Android criou uma coisa dessas? Como o sistema Android está em execução no kernel do Linux Kernel, quando o kernel é anormal, o mecanismo de exceção do kernel reconhece a causa e não pode lidar diretamente com o pânico. Para um sistema Android em execução no Kernel Linux, se houver uma exceção, a camada Android é reiniciada automaticamente, o que dificulta a reprodução do problema e a localização da depuração. Quando ocorre uma exceção na camada Android, as informações de contexto do processo geralmente são exibidas. Salvo na lápide (lápide) para facilitar a depuração.
A imagem acima é um diagrama clássico da arquitetura do sistema Android, e nossa lápide é preparada principalmente para o processo da camada Nativa, usada principalmente para analisar o NativeCrash. Como todo o sistema do Kernel Crash está em pânico diretamente, o kernel imprime o rastreamento de chamada correspondente e haverá uma exceção correspondente lançada para o erro de código da camada Java. Portanto, a lápide é preparada principalmente para o processo da camada nativa.
Lápide
Como é a lápide? Quando ocorre uma exceção no sistema Android, o arquivo de marca de exclusão correspondente será gerado no diretório / data / tombstones
root:/data/tombstones # ls -l
-rw-r----- 1 tombstoned system 3454991 2020-03-13 18:10 tombstone_00
-rw-rw-rw- 1 root root 0 2020-03-14 10:28 tombstone_01
-rw-r----- 1 root root 3454991 2020-03-14 10:29 tombstone_02
-rw-r----- 1 root root 3454991 2020-03-14 10:29 tombstone_03
Abra um arquivo e veja como é a lápide
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'dev/good_dev/2020.3.6_china_dev_test:user/test-keys'
Revision: '0'
ABI: 'arm'
Timestamp: 2020-03-07 02:46:27+0800
pid: 23051, tid: 23051, name: .tencent.qqlive >>> com.tencent.qqlive <<<
uid: 10256
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xdb3fb000
r0 db3f9000 r1 00000000 r2 00023780 r3 db3fb000
r4 cd5ef340 r5 db3f9000 r6 e7a1e260 r7 cd62c6e0
r8 cd668190 r9 ffc417a8 r10 00000001 r11 d1ffa760
ip 00000000 sp ffc41768 lr b9466590 pc e79bfd58
backtrace:
#00 pc 0005dd58 /apex/com.android.runtime/lib/bionic/libc.so (memset_a7+48) (BuildId: dcf0e174e93e33d22f35a631ba9c0de5)
#01 pc 0001258c /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/lib/arm/libmarsxlog.so (LogBuffer::__Clear()+36) (BuildId: 05f64491a5d2ace3d88e1623fefbc695c32396ba)
#02 pc 0000ff68 /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/lib/arm/libmarsxlog.so (appender_open(TAppenderMode, char const*, char const*, char const*)+560) (BuildId: 05f64491a5d2ace3d88e1623fefbc695c32396ba)
#03 pc 00010ca8 /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/lib/arm/libmarsxlog.so (appender_open_with_cache(TAppenderMode, std::string const&, std::string const&, char const*, char const*)+1652) (BuildId: 05f64491a5d2ace3d88e1623fefbc695c32396ba)
#04 pc 000051cc /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/lib/arm/libmarsxlog.so (Java_com_tencent_mars_xlog_Xlog_appenderOpen+428) (BuildId: 05f64491a5d2ace3d88e1623fefbc695c32396ba)
#05 pc 000db673 /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/oat/arm/base.odex (art_jni_trampoline+210)Esse arquivo é relativamente longo, atualmente postamos apenas uma parte, o conteúdo desta seção não é para analisar o significado do conteúdo da lápide, esta seção se concentra no processo de geração desse arquivo, no entendimento de como ele é gerado e, em seguida, analisamos o significado do conteúdo desse arquivo, E como analisar e resolver esses problemas.
Revisão de exemplo de ponteiro NULL
No maravilhoso passeio pelo ponteiro NULL na seção anterior, explicamos em detalhes as séries de atividades no sistema operacional quando a CPU acessa o ponteiro NULL e, finalmente, imprimimos o familiar "Segmetation Faule" no console. Aqui analisamos, porque esse processo pode ser aplicado ao processo de produção de lápides de hoje.
- Quando a CPU acessa um endereço virtual, ela definitivamente passa pela MMU para verificar o relacionamento virtual-real correspondente
- Quando o endereço virtual for ilegal, a unidade de hardware da MMU acionará uma exceção e a CPU irá para a tabela de vetores de exceção para executar a exceção correspondente.
- Após o processamento, a exceção do kernel do Linux no espaço do usuário é sinalizada para o processo correspondente.
- Uma vez que o processo receba o sinal, ele executará a função de processamento de sinal correspondente.
- A instalação das funções de processamento de sinal geralmente é feita no glibc, e o glibc fará o processamento padrão para todos os sinais comuns.
De volta ao sistema Android, quando um processo nativo dispara um ponteiro NULL, primeiro a CPU recebe a exceção correspondente e, em seguida, executa a exceção; em seguida, o sinal SIGSEGV ocorre e a função de processamento do sinal processa o sinal e processa o sinal. No processo, a cena do processo será salva e, finalmente, a lápide será deixada para as gerações futuras adorarem.
A partir da descrição acima, provavelmente adivinhámos o processo geral de implementação da lápide e, em seguida, verificaremos a conjectura.
Como o processo funciona
Aqui está uma breve descrição de como um processo é executado no Android. Aqui usamos o aplicativo WeChat como exemplo
- O aplicativo WeChat é armazenado pela primeira vez no UFS, dispositivo de armazenamento de instruções EMMC
- Quando o usuário clica no ícone do aplicativo WeChat, o sistema operacional carrega o aplicativo WeChat do Flash na memória principal
- Definitivamente tem que passar pelo comando similar da bifurcação para criar o processo correspondente
- Após a criação do processo, você precisa carregar o conteúdo do WeChat por meio de um comando do tipo exec
- Por fim, o programa / system / bin / linker é responsável por carregar algumas bibliotecas compartilhadas usadas pelo programa WeChat,
- Finalmente, pule para a entrada do programa WeChat para executar
A descrição acima é uma descrição simples de como executar um programa. Vamos examinar diretamente o código / system / bin / linker no sistema Android
代码路径： /bionic/linker/arch/arm64/begin.S
ENTRY(_start)
// Force unwinds to end in this function.
.cfi_undefined x30
mov x0, sp
bl __linker_init
/* linker init returns the _entry address in the main image */
br x0
END(_start)
Primeiro, ele deve pular para o segmento do código do vinculador para executar, pular para a função __linker_init
/*
* This is the entry point for the linker, called from begin.S.
*/
extern "C" ElfW(Addr) __linker_init(void* raw_args) {
tmp_linker_so.base = linker_addr;
tmp_linker_so.size = phdr_table_get_load_size(phdr, elf_hdr->e_phnum);
tmp_linker_so.load_bias = get_elf_exec_load_bias(elf_hdr);
tmp_linker_so.dynamic = nullptr;
tmp_linker_so.phdr = phdr;
tmp_linker_so.phnum = elf_hdr->e_phnum;
tmp_linker_so.set_linker_flag();
return __linker_init_post_relocation(args, tmp_linker_so);
}No Linker_init, de acordo com o endereço do link e as informações do cabeçalho do elfo, para recalcular se é necessário realocar ou algo semelhante
static ElfW(Addr) __attribute__((noinline))
__linker_init_post_relocation(KernelArgumentBlock& args, soinfo& tmp_linker_so) {
// Initialize the linker's static libc's globals
__libc_init_globals();
// Initialize the linker's own global variables
tmp_linker_so.call_constructors();
ElfW(Addr) start_address = linker_main(args, exe_to_load);
INFO("[ Jumping to _start (%p)... ]", reinterpret_cast<void*>(start_address));
}Retorne o endereço inicial do programa executável através da função linker_main e, em seguida, vá para a execução. Vamos nos concentrar na função linker_main
static ElfW(Addr) linker_main(KernelArgumentBlock& args, const char* exe_to_load) {
ProtectedDataGuard guard;
// Register the debuggerd signal handler.
#ifdef __ANDROID__
debuggerd_callbacks_t callbacks = {
.get_abort_message = []() {
return __libc_shared_globals()->abort_msg;
},
.post_dump = ¬ify_gdb_of_libraries,
};
debuggerd_init(&callbacks);
#endif
Focalize aqui, naquele momento, se o sistema android inicializar debggerd_init, esta função seguirá a função de processamento padrão do sinal
void debuggerd_init(debuggerd_callbacks_t* callbacks) {
struct sigaction action;
memset(&action, 0, sizeof(action));
sigfillset(&action.sa_mask);
action.sa_sigaction = debuggerd_signal_handler;
action.sa_flags = SA_RESTART | SA_SIGINFO;
// Use the alternate signal stack if available so we can catch stack overflows.
action.sa_flags |= SA_ONSTACK;
debuggerd_register_handlers(&action);
}
static void __attribute__((__unused__)) debuggerd_register_handlers(struct sigaction* action) {
sigaction(SIGABRT, action, nullptr);
sigaction(SIGBUS, action, nullptr);
sigaction(SIGFPE, action, nullptr);
sigaction(SIGILL, action, nullptr);
sigaction(SIGSEGV, action, nullptr);
#if defined(SIGSTKFLT)
sigaction(SIGSTKFLT, action, nullptr);
#endif
sigaction(SIGSYS, action, nullptr);
sigaction(SIGTRAP, action, nullptr);
sigaction(DEBUGGER_SIGNAL, action, nullptr);
}Pode-se observar que alguns sinais anormais são registrados aqui e a função de processamento de ações do sinal é debuggerd_signal_handler.
Quando ocorre uma exceção
Por exemplo, quando o processo nativo tem um problema de ponteiro nulo, o sinal é gerado pelo kernel do linux e o sinal final é processado pela função debuggerd_signal_handler
debuggerd_signal_handler
static void debuggerd_signal_handler(int signal_number, siginfo_t* info, void* context) {
// Only allow one thread to handle a signal at a time.
int ret = pthread_mutex_lock(&crash_mutex);
if (ret != 0) {
async_safe_format_log(ANDROID_LOG_INFO, "libc", "pthread_mutex_lock failed: %s", strerror(ret));
return;
}
log_signal_summary(info);
}Use pthread_mutex_lock para impedir que vários threads processem sinais ao mesmo tempo e, em seguida, chame a função log_signal_summary para imprimir algumas informações
async_safe_format_log(ANDROID_LOG_FATAL, "libc",
"Fatal signal %d (%s), code %d (%s%s)%s in tid %d (%s), pid %d (%s)",
info->si_signo, get_signame(info), info->si_code, get_sigcode(info),
sender_desc, addr_desc, __gettid(), thread_name, self_pid, main_thread_name)O objetivo de fazer isso aqui é impedir que as ações subseqüentes cometam erros e, finalmente, é impossível determinar qual processo cometeu o erro.Aqui, algumas informações importantes são impressas primeiro. Você pode encontrar as informações correspondentes em logcat
libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xdb3fb000 in tid 23051 (.tencent.qqlive), pid 23051 (.tencent.qqlive)- Num de sinal, por exemplo, o sinal 11 representa SIGSEGV
- O código do sinal SEGV_MAPERR significa que o mapeamento está errado
- endereço de falha, o endereço do erro
- tid: ID do encadeamento correspondente
- pid: o ID do processo correspondente.Se houver vários threads em um processo, o ID de cada thread será diferente.
pid_t child_pid =
clone(debuggerd_dispatch_pseudothread, pseudothread_stack,
CLONE_THREAD | CLONE_SIGHAND | CLONE_VM | CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID,
&thread_info, nullptr, nullptr, &thread_info.pseudothread_tid);
if (child_pid == -1) {
fatal_errno("failed to spawn debuggerd dispatch thread");
}
// Wait for the child to start...
futex_wait(&thread_info.pseudothread_tid, -1);
// and then wait for it to terminate.
futex_wait(&thread_info.pseudothread_tid, child_pid);Em seguida, é feita a chamada do sistema clone, clonar um segmento pseudo-pseudo-pseudo-pseudo, para despachar para processar o sinal, aqui aguardando o início e o fim do processo filho
debuggerd_dispatch_pseudothread
pid_t crash_dump_pid = __fork();
if (crash_dump_pid == -1) {
async_safe_format_log(ANDROID_LOG_FATAL, "libc",
"failed to fork in debuggerd signal handler: %s", strerror(errno));
} else if (crash_dump_pid == 0) {
async_safe_format_buffer(main_tid, sizeof(main_tid), "%d", thread_info->crashing_tid);
async_safe_format_buffer(pseudothread_tid, sizeof(pseudothread_tid), "%d",
thread_info->pseudothread_tid);
async_safe_format_buffer(debuggerd_dump_type, sizeof(debuggerd_dump_type), "%d",
get_dump_type(thread_info));
execle(CRASH_DUMP_PATH, CRASH_DUMP_NAME, main_tid, pseudothread_tid, debuggerd_dump_type,
nullptr, nullptr);
async_safe_format_log(ANDROID_LOG_FATAL, "libc", "failed to exec crash_dump helper: %s",
strerror(errno));
return 1;
}Crie um encadeamento filho através da bifurcação no pseudo encadeamento, o encadeamento filho recém-criado é transferido para executar o programa crash_dump64 por meio da chamada do sistema execle, e o processo pai está aqui para aguardar a saída do processo crash_dump
processo crash_dump
pid_t forkpid = fork();
if (forkpid == -1) {
PLOG(FATAL) << "fork failed";
} else if (forkpid == 0) {
fork_exit_read.reset();
} else {
// We need the pseudothread to live until we get around to verifying the vm pid against it.
// The last thing it does is block on a waitpid on us, so wait until our child tells us to die.
fork_exit_write.reset();
char buf;
TEMP_FAILURE_RETRY(read(fork_exit_read.get(), &buf, sizeof(buf)));
_exit(0);
}O processo crash_dump bifurca-se diretamente em um novo processo, o processo pai aguarda o processo filho através da leitura e o processo filho continua a executar a tarefa de crash_dump
// Get the process name (aka cmdline).
std::string process_name = get_process_name(g_target_thread);
// Collect the list of open files.
OpenFilesList open_files;
{
ATRACE_NAME("open files");
populate_open_files_list(&open_files, g_target_thread);
}- Obtenha o nome do processo, obtenha o nome do processo através de / proc / PID / cmdline
- Se vários arquivos forem abertos por esse processo, é possível obter quantos arquivos são abertos por / proc / PID / fd /
{
ATRACE_NAME("ptrace");
for (pid_t thread : threads) {
// Trace the pseudothread separately, so we can use different options.
if (thread == pseudothread_tid) {
continue;
}
if (!ptrace_seize_thread(target_proc_fd, thread, &error)) {
bool fatal = thread == g_target_thread;
LOG(fatal ? FATAL : WARNING) << error;
}
ThreadInfo info;
info.pid = target_process;
info.tid = thread;
info.uid = getuid();
info.process_name = process_name;
info.thread_name = get_thread_name(thread);
if (!ptrace_interrupt(thread, &info.signo)) {
PLOG(WARNING) << "failed to ptrace interrupt thread " << thread;
ptrace(PTRACE_DETACH, thread, 0, 0);
continue;
}
if (thread == g_target_thread) {
// Read the thread's registers along with the rest of the crash info out of the pipe.
ReadCrashInfo(input_pipe, &siginfo, &info.registers, &abort_msg_address,
&fdsan_table_address);
info.siginfo = &siginfo;
info.signo = info.siginfo->si_signo;
} else {
info.registers.reset(unwindstack::Regs::RemoteGet(thread));
if (!info.registers) {
PLOG(WARNING) << "failed to fetch registers for thread " << thread;
ptrace(PTRACE_DETACH, thread, 0, 0);
continue;
}
}
thread_info[thread] = std::move(info);
}
}O loop for percorre todos os threads neste processo, lê a operação pinfo do processo de thread em cada processo e lê as informações de falha do thread de destino.
// Detach from all of our attached threads before resuming.
for (const auto& [tid, thread] : thread_info) {
int resume_signal = thread.signo == DEBUGGER_SIGNAL ? 0 : thread.signo;
if (wait_for_gdb) {
resume_signal = 0;
if (tgkill(target_process, tid, SIGSTOP) != 0) {
PLOG(WARNING) << "failed to send SIGSTOP to " << tid;
}
}
LOG(DEBUG) << "detaching from thread " << tid;
if (ptrace(PTRACE_DETACH, tid, 0, resume_signal) != 0) {
PLOG(ERROR) << "failed to detach from thread " << tid;
}
}Depois de ler as informações de travamento, desanexe cada
tombstoned_connect
{
ATRACE_NAME("tombstoned_connect");
LOG(INFO) << "obtaining output fd from tombstoned, type: " << dump_type;
g_tombstoned_connected =
tombstoned_connect(g_target_thread, &g_tombstoned_socket, &g_output_fd, dump_type);
}Conectado ao processo de marca para exclusão, conectado através do soquete.
// si_value is special when used with DEBUGGER_SIGNAL.
// 0: dump tombstone
// 1: dump backtrace
if (!fatal_signal) {
int si_val = siginfo.si_value.sival_int;
if (si_val == 0) {
backtrace = false;
} else if (si_val == 1) {
backtrace = true;
} else {
LOG(WARNING) << "unknown si_value value " << si_val;
}
}Faça julgamentos diferentes com base nos parâmetros passados pela lápide.Quando o parâmetro = 0, significa despejar lápide.Quando é igual a 1, apenas o backtrace é despejado.
if (backtrace) {
ATRACE_NAME("dump_backtrace");
dump_backtrace(std::move(g_output_fd), &unwinder, thread_info, g_target_thread);
} else {
{
ATRACE_NAME("fdsan table dump");
populate_fdsan_table(&open_files, unwinder.GetProcessMemory(), fdsan_table_address);
}
{
ATRACE_NAME("engrave_tombstone");
engrave_tombstone(std::move(g_output_fd), &unwinder, thread_info, g_target_thread,
abort_msg_address, &open_files, &amfd_data);
}
}A lápide final é gerada por engrave_tombstone.
engrave_tombstone
void engrave_tombstone(unique_fd output_fd, unwindstack::Unwinder* unwinder,
const std::map<pid_t, ThreadInfo>& threads, pid_t target_thread,
uint64_t abort_msg_address, OpenFilesList* open_files,
std::string* amfd_data) {
// don't copy log messages to tombstone unless this is a dev device
bool want_logs = android::base::GetBoolProperty("ro.debuggable", false);
log_t log;
log.current_tid = target_thread;
log.crashed_tid = target_thread;
log.tfd = output_fd.get();
log.amfd_data = amfd_data;
_LOG(&log, logtype::HEADER, "*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***\n");
dump_header_info(&log);
dump_timestamp(&log, time(nullptr));
auto it = threads.find(target_thread);
if (it == threads.end()) {
LOG(FATAL) << "failed to find target thread";
}
dump_thread(&log, unwinder, it->second, abort_msg_address, true);
if (want_logs) {
dump_logs(&log, it->second.pid, 50);
}
for (auto& [tid, thread_info] : threads) {
if (tid == target_thread) {
continue;
}
dump_thread(&log, unwinder, thread_info, 0, false);
}
if (open_files) {
_LOG(&log, logtype::OPEN_FILES, "\nopen files:\n");
dump_open_files_list(&log, *open_files, " ");
}
if (want_logs) {
dump_logs(&log, it->second.pid, 0);
}
análise de exemplo de arquivo tombstone
O log icônico da lápide começa: "*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** * ** *** "
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***informações da cabeça de impressão dump_header_info
static void dump_header_info(log_t* log) {
auto fingerprint = GetProperty("ro.build.fingerprint", "unknown");
auto revision = GetProperty("ro.revision", "unknown");
_LOG(log, logtype::HEADER, "Build fingerprint: '%s'\n", fingerprint.c_str());
_LOG(log, logtype::HEADER, "Revision: '%s'\n", revision.c_str());
_LOG(log, logtype::HEADER, "ABI: '%s'\n", ABI_STRING);
}Exemplos são os seguintes:
Build fingerprint: 'dev/good_dev/2020.3.6_china_dev_test:user/test-keys'
Revision: '0'
ABI: 'arm'dump_timestamp informações de tempo de impressão
static void dump_timestamp(log_t* log, time_t time) {
struct tm tm;
localtime_r(&time, &tm);
char buf[strlen("1970-01-01 00:00:00+0830") + 1];
strftime(buf, sizeof(buf), "%F %T%z", &tm);
_LOG(log, logtype::HEADER, "Timestamp: %s\n", buf);
}Imprima o horário da viagem de negócios, o exemplo é o seguinte:
Timestamp: 2020-03-07 02:46:27+0800dump_thread_info imprime informações de threads
static void dump_thread_info(log_t* log, const ThreadInfo& thread_info) {
// Blacklist logd, logd.reader, logd.writer, logd.auditd, logd.control ...
// TODO: Why is this controlled by thread name?
if (thread_info.thread_name == "logd" ||
android::base::StartsWith(thread_info.thread_name, "logd.")) {
log->should_retrieve_logcat = false;
}
_LOG(log, logtype::HEADER, "pid: %d, tid: %d, name: %s >>> %s <<<\n", thread_info.pid,
thread_info.tid, thread_info.thread_name.c_str(), thread_info.process_name.c_str());
_LOG(log, logtype::HEADER, "uid: %d\n", thread_info.uid);
}Exemplos são os seguintes:
pid: 23051, tid: 23051, name: .tencent.qqlive >>> com.tencent.qqlive <<<
uid: 10256dump_signal_info imprime informações do sinal
_LOG(log, logtype::HEADER, "signal %d (%s), code %d (%s%s), fault addr %s\n",
thread_info.siginfo->si_signo, get_signame(thread_info.siginfo),
thread_info.siginfo->si_code, get_sigcode(thread_info.siginfo), sender_desc, addr_desc);Exemplos são os seguintes:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xdb3fb000dump_probable_cause imprime informações sobre possíveis causas
cause = StringPrintf("null pointer dereference");
} else if (si->si_addr == reinterpret_cast<void*>(0xffff0ffc)) {
cause = "call to kuser_helper_version";
} else if (si->si_addr == reinterpret_cast<void*>(0xffff0fe0)) {
cause = "call to kuser_get_tls";
} else if (si->si_addr == reinterpret_cast<void*>(0xffff0fc0)) {
cause = "call to kuser_cmpxchg";
} else if (si->si_addr == reinterpret_cast<void*>(0xffff0fa0)) {
cause = "call to kuser_memory_barrier";
} else if (si->si_addr == reinterpret_cast<void*>(0xffff0f60)) {
cause = "call to kuser_cmpxchg64";
}
if (!cause.empty()) _LOG(log, logtype::HEADER, "Cause: %s\n", cause.c_str());Exemplos são os seguintes:
Cause: null pointer dereferencedump_registers imprime informações de registro
r0 db3f9000 r1 00000000 r2 00023780 r3 db3fb000
r4 cd5ef340 r5 db3f9000 r6 e7a1e260 r7 cd62c6e0
r8 cd668190 r9 ffc417a8 r10 00000001 r11 d1ffa760
ip 00000000 sp ffc41768 lr b9466590 pc e79bfd58log_backtrace imprime informações de backtrace
backtrace:
#00 pc 0005dd58 /apex/com.android.runtime/lib/bionic/libc.so (memset_a7+48) (BuildId: dcf0e174e93e33d22f35a631ba9c0de5)
#01 pc 0001258c /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/lib/arm/libmarsxlog.so (LogBuffer::__Clear()+36) (BuildId: 05f64491a5d2ace3d88e1623fefbc695c32396ba)
#02 pc 0000ff68 /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/lib/arm/libmarsxlog.so (appender_open(TAppenderMode, char const*, char const*, char const*)+560) (BuildId: 05f64491a5d2ace3d88e1623fefbc695c32396ba)
#03 pc 00010ca8 /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/lib/arm/libmarsxlog.so (appender_open_with_cache(TAppenderMode, std::string const&, std::string const&, char const*, char const*)+1652) (BuildId: 05f64491a5d2ace3d88e1623fefbc695c32396ba)
#04 pc 000051cc /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/lib/arm/libmarsxlog.so (Java_com_tencent_mars_xlog_Xlog_appenderOpen+428) (BuildId: 05f64491a5d2ace3d88e1623fefbc695c32396ba)
#05 pc 000db673 /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/oat/arm/base.odex (art_jni_trampoline+210)informações da pilha de impressão dump_stack
stack:
ffc41728 cd422400 [anon:libc_malloc]
ffc4172c b946cc2b /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/lib/arm/libmarsxlog.so
ffc41730 ffc417b0 [stack]
ffc41734 db3f9000 /data/data/com.tencent.qqlive/files/log/QQLiveLog.mmap2
ffc41738 db3f9000 /data/data/com.tencent.qqlive/files/log/QQLiveLog.mmap2
ffc4173c e7a1e260 [anon:.bss]
ffc41740 ffc417b0 [stack]
ffc41744 00001252
ffc41748 e7a1e260 [anon:.bss]
ffc4174c b946cc7b /data/app/com.tencent.qqlive-NGSZiLGPko8T894J1J65kQ==/lib/arm/libmarsxlog.so
ffc41750 00000000informações de memória de impressão dump_memory_and_code
memory near r0 (/data/data/com.tencent.qqlive/files/log/QQLiveLog.mmap2):
db3f8fe0 -------- -------- -------- -------- ................
db3f8ff0 -------- -------- -------- -------- ................
db3f9000 02000109 00096a02 00000000 00000000 .....j..........
db3f9010 bd0aa200 5ef280e3 000000cd 00000000 .......^........
db3f9020 00000000 00000000 00000000 c6e85800 .............X..
db3f9030 00000012 00000000 00000000 00000000 ................
db3f9040 00000000 d5ef2800 838b8a0c 74d2c701 .....(.........t
db3f9050 05132305 73430323 ccd0cf20 cadcd4ca .#..#.Cs .......
db3f9060 1d2e0cd0 6c646d17 03a86a60 622dcd24 .....mdl`j..$.-b
db3f9070 8c0c8da3 8c0d740c 15cc0d75 0c2c0db4 .....t..u.....,.
db3f9080 8c0c140c accc4cac b963cc8c 00000000 .....L....c.....
db3f9090 494affff c92851cd c8554dcc 48512d2f ..JI.Q(..MU./-QH
db3f90a0 2d49cccb 14ad7306 0000b80c ffff0000 ..I-.s..........
db3f90b0 512d4f4a 2c4dcdc8 72180a80 00000001 JO-Q..M,...r....
db3f90c0 75f2ffff 0f8e0a0c 52b1f20d 294fcdc8 ...u.......R..O)
db3f90d0 f7d549cd e62a2c4d 00000002 8b02ffff .I..M,*.........dump_all_maps imprime informações do mapa
memory map (2172 entries): (fault address prefixed with --->)
0a125000-0a126fff r-- 0 2000 /system/bin/app_process32 (BuildId: 4b3fcbf21f6cb09225ed60ef016d3f87)
0a127000-0a129fff r-x 2000 3000 /system/bin/app_process32 (BuildId: 4b3fcbf21f6cb09225ed60ef016d3f87)
0a12a000-0a12afff r-- 5000 1000 /system/bin/app_process32 (BuildId: 4b3fcbf21f6cb09225ed60ef016d3f)
0a12b000-0a12bfff rw- 0 1000
12c00000-15fbffff rw- 0 33c0000 [anon:dalvik-main space (region space)]
15fc0000-161bffff rw- 0 200000 [anon:dalvik-main space (region space)] dump_log_file (log, pid, "system", tail); imprime informações do log do sistema
dump_log_file (log, pid, "main", tail); imprime informações do mainlog
--------- tail end of log main
03-07 02:46:27.072 23051 23051 W System.err: at com.tencent.qqlive.ona.base.QQLiveApplication.attachBaseContext(QQLiveApplication.java:1223)
03-07 02:46:27.072 23051 23051 W System.err: at com.tencent.qqlive.ona.base.QQLiveApplicationWrapper.attachBaseContext(QQLiveApplicationWrapper.java:197)
03-07 02:46:27.073 23051 23051 W System.err: at android.app.Application.attach(Application.java:376)Sumário
- Quando ocorre uma exceção no processo nativo, como um ponteiro NULL
- O sistema operacional irá para o endereço da tabela de vetores de exceção para lidar com a exceção e enviará um sinal
- A função de processamento de sinal registrada em debugged_init será processada
- Crie um pseudo thread para iniciar o processo crash_dump, crash_dump obterá as informações de travamento de cada thread no processo atual
- O processo marcado para exclusão é iniciado quando o computador está ligado e o soquete é registrado quando o computador está ligado, aguardando o monitoramento
- Ao conectar-se ao processo marcado para exclusão em crash_dump, um descritor de arquivo em / data / tombstones / será retornado com base no dump_type passado
- O processo crash_dump posteriormente grava os detalhes de todos os encadeamentos no arquivo tombstone por meio da função engrave_tombstone
- Em seguida, o arquivo tombstone_XX correspondente é gerado em / data / tombstones
