* Trace/breakpoint trap. [not found] <895597245.1533806.1619862429301.ref@mail.yahoo.com> @ 2021-05-01 9:47 ` Jason Long 2021-05-01 21:31 ` Simon Marchi 0 siblings, 1 reply; 6+ messages in thread From: Jason Long @ 2021-05-01 9:47 UTC (permalink / raw) To: Eli Zaretskii 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Trace/breakpoint trap. 2021-05-01 9:47 ` Trace/breakpoint trap Jason Long @ 2021-05-01 21:31 ` Simon Marchi 2021-05-14 19:45 ` Jason Long 0 siblings, 1 reply; 6+ messages in thread From: Simon Marchi @ 2021-05-01 21:31 UTC (permalink / raw) To: Jason Long, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Trace/breakpoint trap. 2021-05-01 21:31 ` Simon Marchi @ 2021-05-14 19:45 ` Jason Long 2021-05-14 19:52 ` Simon Marchi 0 siblings, 1 reply; 6+ messages in thread From: Jason Long @ 2021-05-14 19:45 UTC (permalink / raw) To: Eli Zaretskii via Gdb, Simon Marchi 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Trace/breakpoint trap. 2021-05-14 19:45 ` Jason Long @ 2021-05-14 19:52 ` Simon Marchi 2021-05-14 20:08 ` Jason Long 0 siblings, 1 reply; 6+ messages in thread From: Simon Marchi @ 2021-05-14 19:52 UTC (permalink / raw) To: Jason Long, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Trace/breakpoint trap. 2021-05-14 19:52 ` Simon Marchi @ 2021-05-14 20:08 ` Jason Long 2021-05-14 22:01 ` Jeffrey Walton 0 siblings, 1 reply; 6+ messages in thread From: Jason Long @ 2021-05-14 20:08 UTC (permalink / raw) To: Eli Zaretskii via Gdb, Simon Marchi 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Trace/breakpoint trap. 2021-05-14 20:08 ` Jason Long @ 2021-05-14 22:01 ` Jeffrey Walton 0 siblings, 0 replies; 6+ messages in thread From: Jeffrey Walton @ 2021-05-14 22:01 UTC (permalink / raw) To: Jason Long; +Cc: 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-05-14 22:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <895597245.1533806.1619862429301.ref@mail.yahoo.com>
2021-05-01 9:47 ` Trace/breakpoint trap Jason Long
2021-05-01 21:31 ` Simon Marchi
2021-05-14 19:45 ` Jason Long
2021-05-14 19:52 ` Simon Marchi
2021-05-14 20:08 ` Jason Long
2021-05-14 22:01 ` Jeffrey Walton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).