GDB how to get backtrace on exit in NASM?

Question

Backtrace in GDB is more limited in NASM than in C, but typically I see this type of backtrace within the program body:

#0  set_data () at ProgramName.asm:863
#1  0x0000000000000000 in ?? ()

I have a two-core program (each core assigned to a different task) and the final core segfaults on exit (ret). At that point all I see with bt (backtrace) is:

(gdb) bt
#0  0x0000000000000100 in ?? ()
#1  0x0000000000000000 in ?? ()

That's in NASM -- I imagine C would show me more information. My question is, how can I see more info to debug a segfault on exit (ret) from the program. At the point of the segfault, the other thread (core) has already exited and this is the state of the threads:

(gdb) info threads
  Id   Target Id         Frame
  1    Thread 0x7ffff7fea740 (LWP 22160) "Call_Create_Thr"  0x00007ffff6ff3d2d in __GI___pthread_timedjoin_ex   (threadid=140737126745856, thread_return=0x0,
    abstime=0x0, block=<optimized out>) at  pthread_join_common.c:89

* 3    Thread 0x7fffea724700 (LWP 22165) "Call_Create_Thr"  0x0000000000000100 in ?? ()

I need to see where Thread 3 (0x7fffea724700) segfaults. The bt doesn't reveal enough info.

One question suggested stack corruption. In this program, I store some variables on the stack; I begin with sub rsp,64 and end with add rsp,64, so that should take care of the stack, but that may have something to do with the sefault on exit and lack of backtrace info.

How can I see more info with backtrace where I segfault on exit in NASM?

Answer 1

I need to see where Thread 3 (0x7fffea724700) segfaults.

It segfaults when $rip gets a value of 0x100 . How the code ends up there we can't tell without MCVE .

debug a segfault on exit (ret) from the program.

Exit and ret(urn) are not the same thing. Are you returning to your caller when the task was created without one?