Re: [Crash-utility] using crash for ARM

----- Original Message ----- For starters, as Mika suggested, you should try your best to use the actual vmlinux file that is being run on the live system. If the running kernel's vmlinux file does not have debuginfo data, and you are using a similar kernel along with the running kernel's System.map file, then you must be sure that the "other" vmlinux that you are using is as close as possible to the running kernel. There are no guarantees that using a System.map file will work. Anyway, looking at the log file, I'm not sure why there's non-crash related data intermingled with the crash -d8 output, i.e., like this: ... c00dfc08 clk_enable c00dfc50 clk_debug_set_enable c00dfcac clk_[ 1866.844757] ##> wifi_suspend [ 1866.856903] i2c i2c-1: mpu_dev_suspend, called regulator_disable. Status: 0 [ 1866.856933] mpu_dev_suspend: Suspend handler executed [ 1866.872528] PM: suspend of devices complete after 27.886 msecs [ 1866.872558] PM: suspend devices took 0.030 seconds [ 1866.873077] PM: late suspend of devices complete after 0.457 msecs [ 1866.873535] PM: early resume of devices complete after 0.183 msecs [ 1866.874481] i2c i2c-1: mpu_dev_resume, called regulator_enable. Status: 0 [ 1866.874511] mpu_dev_resume: Resume handler executed [ 1866.874572] wakeup wake lock: bcmpmu_i2c [ 1866.874908] get_update_rate: rate = 112000 [ 1866.874938] get_update_rate: rate = 112000 [ 1866.876434] ##> wifi_resume [ 1866.892822] PM: resume of devices complete after 19.007 msecs [ 1866.893676] PM: resume devices took 0.020 seconds reset c00dfd4c clk_debug_reset c00dfd90 clk_init c00dfe10 clk_register ... Regardless of that, I was looking for a readmem() call, or other debug statement that might help pinpoint the failure location. The best that can be inferred from the log data are the GNU_GET_DATATYPE debug statements at the end: $ grep GNU_GET_DATATYPE teraterm.log GNU_GET_DATATYPE[runqueue]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[prio_array]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[prio_array]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[prio_array]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[irq_desc_t]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[hw_interrupt_type]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[timer_vec_root]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[timer_vec]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[tvec_root_s]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[softirq_state]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[desc_struct]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[kallsyms_header]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[mem_section]: returned via gdb_error_hook (1 buffer in use) GNU_GET_DATATYPE[note_buf_t]: returned via gdb_error_hook (1 buffer in use) $ and have called machdep_init(POST_GDB) from here in main.c:main_loop() } else if (!(pc->flags & MINIMAL_MODE)) { read_in_kernel_config(IKCFG_INIT); kernel_init(); =====> machdep_init(POST_GDB); vm_init(); machdep_init(POST_VM); module_init(); help_init(); task_init(); vfs_init(); net_init(); dev_init(); machdep_init(POST_INIT); } which calls into arm.c:arm_init(POST_GDB). That function has successfully made it past the STRUCT_SIZE_INIT(note_buf, "note_buf_t") call: /* * We need to have information about note_buf_t which is used to * hold ELF note containing registers and status of the thread * that panic'd. */ =====> STRUCT_SIZE_INIT(note_buf, "note_buf_t"); STRUCT_SIZE_INIT(elf_prstatus, "elf_prstatus"); MEMBER_OFFSET_INIT(elf_prstatus_pr_pid, "elf_prstatus", "pr_pid"); MEMBER_OFFSET_INIT(elf_prstatus_pr_reg, "elf_prstatus", "pr_reg"); break; But the next STRUCT_SIZE_INIT() for "elf_prstatus" apparently never got completed. In any case, it ended up in open_tmpfile2(): $ tail teraterm.log GETBUF(128 -> 0) FREEBUF(0) GETBUF(128 -> 0) FREEBUF(0) GETBUF(128 -> 0) FREEBUF(0) crash: cannot open secondary temporary file 1|shell@android:/system # $ Although it's not clear how it's ending up in open_tmpfile2(), it's certainly of interest that the tmpfile() call is failing: void open_tmpfile2(void) { if (pc->tmpfile2) error(FATAL, "recursive secondary temporary file usage\n"); if ((pc->tmpfile2 = tmpfile()) == NULL) error(FATAL, "cannot open secondary temporary file\n"); rewind(pc->tmpfile2); } The man page for tmpfile() shows these reasons: RETURN VALUE The tmpfile() function returns a stream descriptor, or NULL if a unique filename cannot be generated or the unique file cannot be opened. In the latter case, errno is set to indicate the error. ERRORS EACCES Search permission denied for directory in file’s path prefix. EEXIST Unable to generate a unique filename. EINTR The call was interrupted by a signal. EMFILE Too many file descriptors in use by the process. ENFILE Too many files open in the system. ENOSPC There was no room in the directory to add the new filename. EROFS Read-only filesystem. A couple things you might try: (1) Put a perror() after the tmpfile() call to determine which errno is being returned. (2) Set "pc->flags |= DROP_CORE;" prior to the tmpfile() call. Like this: void open_tmpfile2(void) { if (pc->tmpfile2) error(FATAL, "recursive secondary temporary file usage\n"); + pc->flags |= DROP_CORE; - if ((pc->tmpfile2 = tmpfile()) == NULL) + if ((pc->tmpfile2 = tmpfile()) == NULL) { + perror("tmpfile"); error(FATAL, "cannot open secondary temporary file\n"); + } pc->flags &= ~DROP_CORE; rewind(pc->tmpfile2); } Then get a backtrace by running gdb on the resultant core file, or just run the whole session from gdb. Dave