Hi Dave, > ----- Original Message ----- > > > Hello Lei, > > > > > > > > > And it appears that target_read_stack() can be modified in the same > > > way > > > that target_read_memory() has been, since they are essentially the > > > same: > > > > > > int > > > target_read_stack (CORE_ADDR memaddr, gdb_byte *myaddr, int len) > > > { > > > } > > > > > > So just try cut-and-pasting the same #ifdef CRASH_MERGE section into > > > target_read_stack(). > > > > Yep, it did solve my issue, now the backtrace would unwind happily to > > the next frame. > > > > While I am trying to apply the similar logic to another thread > > instead of current panic one, I find the gdb would directly complain > > for "<segmentation violation in gdb> ". Haven't figure out what > > happened there... > > When gdb is invoked, it passes through this in gdb_interface(): > > if (!(pc->flags & DROP_CORE)) > SIGACTION(SIGSEGV, restart, &pc->sigaction, NULL); > else > SIGACTION(SIGSEGV, SIG_DFL, &pc->sigaction, NULL); > > which causes any segmentation violations in gdb code to restart back > to the command prompt. To get an actual core dump (to set DROP_CORE), > try this: > > crash> set core on > core: on (drop core on error message) > crash> > > If you do the above, however, any call to error(FATAL, ...), > error(INFO, ...), or error(WARNING, ...) will also generate > a core dump. If that gets in the way of your gdb testing, you > should just comment out the "if-else" statement above. This seems interesting function; I would give it a try. :) Thanks, Lei -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility