Trace/breakpoint trap.

Trace/breakpoint trap.

[Jason Long via Gdb]

Hello,
I installed the Atomic Cryptocurrency Wallet on my Debian Linux and when I want to launch it, then it shows me "Trace/breakpoint trap" error.
I want to find the reason of it with GDB.
I launched it inside the GDB:

(gdb) run
Starting program: /usr/bin/atomic 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff2eb7700 (LWP 12453)]
[Detaching after fork from child process 12454]


Thread 1 "atomic" received signal SIGTRAP, Trace/breakpoint trap.
0x000055555a7556f3 in ?? ()

What is the next step?


Thank you.

Re: Trace/breakpoint trap.

[Simon Marchi via Gdb]

On 2021-05-01 5:47 a.m., Jason Long via Gdb wrote:
> Hello,
> I installed the Atomic Cryptocurrency Wallet on my Debian Linux and when I want to launch it, then it shows me "Trace/breakpoint trap" error.
> I want to find the reason of it with GDB.
> I launched it inside the GDB:
> 
> (gdb) run
> Starting program: /usr/bin/atomic 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7ffff2eb7700 (LWP 12453)]
> [Detaching after fork from child process 12454]
> 
> 
> Thread 1 "atomic" received signal SIGTRAP, Trace/breakpoint trap.
> 0x000055555a7556f3 in ?? ()
> 
> What is the next step?
> 
> 
> Thank you.
> 
Hi,

You could start by using "bt" to get a sense of where you are stopped.
You could try to find out in which object file address
0x000055555a7556f3 falls.  You can use "info target" for that.
Depending on what you find, the next steps depend on what you find (it's
investigative work, so there's not pre-defined path).

Simon

Re: Trace/breakpoint trap.

[Jason Long via Gdb]

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/

What is the next step?


On Sunday, May 2, 2021, 02:01:56 AM GMT+4:30, Simon Marchi <simon.marchi@polymtl.ca> wrote: 







On 2021-05-01 5:47 a.m., Jason Long via Gdb wrote:
> Hello,
> I installed the Atomic Cryptocurrency Wallet on my Debian Linux and when I want to launch it, then it shows me "Trace/breakpoint trap" error.
> I want to find the reason of it with GDB.
> I launched it inside the GDB:
> 
> (gdb) run
> Starting program: /usr/bin/atomic 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7ffff2eb7700 (LWP 12453)]
> [Detaching after fork from child process 12454]
> 
> 
> Thread 1 "atomic" received signal SIGTRAP, Trace/breakpoint trap.
> 0x000055555a7556f3 in ?? ()
> 
> What is the next step?
> 
> 
> Thank you.

> 
Hi,

You could start by using "bt" to get a sense of where you are stopped.
You could try to find out in which object file address
0x000055555a7556f3 falls.  You can use "info target" for that.
Depending on what you find, the next steps depend on what you find (it's
investigative work, so there's not pre-defined path).

Simon

Re: Trace/breakpoint trap.

[Simon Marchi via Gdb]

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

Re: Trace/breakpoint trap.

[Jason Long via Gdb]

Thank you.
Why you selected "0x0000555557425000 - 0x000055555c440280 is .text" ? 
How to build with debug information?
Disassembly? I must use a disassembler?




On Saturday, May 15, 2021, 12:22:53 AM GMT+4:30, Simon Marchi <simon.marchi@polymtl.ca> wrote: 





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

Re: Trace/breakpoint trap.

[Jeffrey Walton via Gdb]

On Fri, May 14, 2021 at 5:39 PM Jason Long via Gdb <gdb@sourceware.org> wrote:
>
> Thank you.
> Why you selected "0x0000555557425000 - 0x000055555c440280 is .text" ?
> How to build with debug information?
> Disassembly? I must use a disassembler?

From the top level directory, where you run configure, change CFLAGS
and CXXFLAGS to include:

  -g3 -O1 -fdebug-prefix-map=${PWD}=/opt/src/wallet

Then, after you perform 'sudo make install', perform the following to
copy the sources to /opt/src/wallet.

IFS= find "./" \( -name '*.h' -o -name '*.hpp' -o -name '*.hxx' -o \
                  -name '*.c' -o -name '*.cc' -o \
                  -name '*.cpp' -o -name '*.cxx' -o -name '*.CC' -o \
                  -name '*.s' -o -name '*.S' \) -print | while read -r file
do
    # This trims the leading "./" in "./foo.c".
    file=$(echo -n "${file}" | tr -s '/' | cut -c 3-);
    cp --parents --preserve=timestamps "${file}" /opt/src/wallet
done

After the sources are in /opt/src/wallet, GDB will start working as expected.

Jeff