Re: Trace/breakpoint trap.

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-05-14 3:45 p.m., Jason Long wrote:> Hello,
> Thank you.
> The "bt" show me:
> 
> (gdb) bt
> #0  0x000055555a7556f3 in ?? ()
> #1  0x00005555590002e0 in ?? ()
> #2  0x000055555a75474c in ?? ()
> #3  0x000055555a75a4a1 in ?? ()
> #4  0x0000555558fffb7c in ?? ()
> #5  0x000055555a75addb in ?? ()
> #6  0x0000555558ffe191 in ?? ()
> #7  0x000055555742527b in ?? ()
> #8  0x00007ffff568509b in __libc_start_main (main=0x555557425130, argc=1, 
>     argv=0x7fffffffe288, init=<optimized out>, fini=<optimized out>, 
>     rtld_fini=<optimized out>, stack_end=0x7fffffffe278)
>     at ../csu/libc-start.c:308
> #9  0x000055555742502a in _start ()
> 
> 
> And "info target" showed me: https://pastebin.ubuntu.com/p/3qT9yhkW3Y/

That tells you you are stopped somewhere in your "atomic" binary, whose
.text section is at:

	0x0000555557425000 - 0x000055555c440280 is .text

It could be useful to have function names, for that you'll need a build
with debug information (or install separate debug information, if
available).

You could try looking at the disassembly just around where you are
stopped, see if it looks like an instruction that could have caused a
trap, like a breakpoint instruction or a call to the "kill" syscall.

It's also possible that this application uses SIGTRAP for its own
purpose.  For example, there could be multiple threads sending SIGTRAPs
to each other.  It's also possible that it's an anti-debugging
technique.

Simon