* The newest gdb 8.3 crash on OpenBSD
@ 2020-01-29 5:44 Nan Xiao
2020-01-30 4:21 ` Simon Marchi
0 siblings, 1 reply; 5+ messages in thread
From: Nan Xiao @ 2020-01-29 5:44 UTC (permalink / raw)
To: gdb
Hi gdb community,
Greeting from me!
I am building the newest gdb 8.3 on OpenBSD 6.6 server (Virtual
machine, amd64). The build is OK, but the gdb will crash when I tried
to use it to debug program:
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00000ec41fa1c506 in x86_dr_stopped_data_address
(state=0xec6da0e4010, addr_p=0x7f7ffffbde70) at
../../gdb/nat/x86-dregs.c:608
#2 0x00000ec41fa1c7a3 in x86_dr_stopped_by_watchpoint
(state=0xec6da0e4010) at ../../gdb/nat/x86-dregs.c:650
#3 0x00000ec41f82ae47 in
x86_nat_target<obsd_nat_target>::stopped_by_watchpoint
(this=0xec6da0e4010) at ../../gdb/x86-nat.h:100
#4 0x00000ec41f84ff71 in watchpoints_triggered (ws=<optimized out>)
at ../../gdb/breakpoint.c:4727
#5 0x00000ec41f9ccb70 in handle_signal_stop (ecs=0x7f7ffffbe2f0) at
../../gdb/infrun.c:5605
#6 0x00000ec41f9c1eeb in handle_inferior_event (ecs=0x7f7ffffbe2f0)
at ../../gdb/infrun.c:5178
#7 0x00000ec41f9c329b in fetch_inferior_event (client_data=<optimized
out>) at ../../gdb/infrun.c:3753
#8 0x00000ec41f95ce59 in gdb_do_one_event () at ../../gdb/event-loop.c:1064
#9 0x00000ec41f95d42d in start_event_loop () at ../../gdb/event-loop.c:371
#10 0x00000ec41f9f3392 in captured_command_loop () at ../../gdb/main.c:331
#11 0x00000ec41f9f2e13 in captured_main (data=<optimized out>) at
../../gdb/main.c:1182
#12 gdb_main (args=<optimized out>) at ../../gdb/main.c:1198
#13 0x00000ec41f7fc378 in main (argc=<optimized out>,
argv=0x7f7ffffbde70) at ../../gdb/gdb.c:32
(gdb) frame 1
#1 0x00000ec41fa1c506 in x86_dr_stopped_data_address
(state=0xec6da0e4010, addr_p=0x7f7ffffbde70) at
../../gdb/nat/x86-dregs.c:608
608 status = x86_dr_low_get_status ();
I tried to step-in debug it, and found it seems to access an invalid
function address:
(top-gdb) display /i $pc
1: x/i $pc
=> 0x76de4af4f5 <x86_dr_stopped_data_address(x86_debug_reg_state*,
unsigned long*)+37>:
mov 0x394874(%rip),%r12 # 0x76de843d70
(top-gdb) ni
0x00000076de4af4fc 608 status = x86_dr_low_get_status ();
1: x/i $pc
=> 0x76de4af4fc <x86_dr_stopped_data_address(x86_debug_reg_state*,
unsigned long*)+44>: mov 0x18(%r12),%r11
(top-gdb)
0x00000076de4af501 608 status = x86_dr_low_get_status ();
1: x/i $pc
=> 0x76de4af501 <x86_dr_stopped_data_address(x86_debug_reg_state*,
unsigned long*)+49>: callq 0x76de28f150 <__llvm_retpoline_r11>
(top-gdb)
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
1: x/i $pc
=> 0x0: <error: Cannot access memory at address 0x0>
I checked the source code, but can't figure out the reasons. Anyone
can give some clues? Thanks very much in advance!
Best Regards
Nan Xiao
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: The newest gdb 8.3 crash on OpenBSD 2020-01-29 5:44 The newest gdb 8.3 crash on OpenBSD Nan Xiao @ 2020-01-30 4:21 ` Simon Marchi 2020-02-01 10:47 ` Nan Xiao 0 siblings, 1 reply; 5+ messages in thread From: Simon Marchi @ 2020-01-30 4:21 UTC (permalink / raw) To: Nan Xiao, gdb On 2020-01-29 12:44 a.m., Nan Xiao wrote: > Hi gdb community, > > Greeting from me! > > I am building the newest gdb 8.3 on OpenBSD 6.6 server (Virtual > machine, amd64). The build is OK, but the gdb will crash when I tried > to use it to debug program: > > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x00000ec41fa1c506 in x86_dr_stopped_data_address > (state=0xec6da0e4010, addr_p=0x7f7ffffbde70) at > ../../gdb/nat/x86-dregs.c:608 > #2 0x00000ec41fa1c7a3 in x86_dr_stopped_by_watchpoint > (state=0xec6da0e4010) at ../../gdb/nat/x86-dregs.c:650 > #3 0x00000ec41f82ae47 in > x86_nat_target<obsd_nat_target>::stopped_by_watchpoint > (this=0xec6da0e4010) at ../../gdb/x86-nat.h:100 > #4 0x00000ec41f84ff71 in watchpoints_triggered (ws=<optimized out>) > at ../../gdb/breakpoint.c:4727 > #5 0x00000ec41f9ccb70 in handle_signal_stop (ecs=0x7f7ffffbe2f0) at > ../../gdb/infrun.c:5605 > #6 0x00000ec41f9c1eeb in handle_inferior_event (ecs=0x7f7ffffbe2f0) > at ../../gdb/infrun.c:5178 > #7 0x00000ec41f9c329b in fetch_inferior_event (client_data=<optimized > out>) at ../../gdb/infrun.c:3753 > #8 0x00000ec41f95ce59 in gdb_do_one_event () at ../../gdb/event-loop.c:1064 > #9 0x00000ec41f95d42d in start_event_loop () at ../../gdb/event-loop.c:371 > #10 0x00000ec41f9f3392 in captured_command_loop () at ../../gdb/main.c:331 > #11 0x00000ec41f9f2e13 in captured_main (data=<optimized out>) at > ../../gdb/main.c:1182 > #12 gdb_main (args=<optimized out>) at ../../gdb/main.c:1198 > #13 0x00000ec41f7fc378 in main (argc=<optimized out>, > argv=0x7f7ffffbde70) at ../../gdb/gdb.c:32 > (gdb) frame 1 > #1 0x00000ec41fa1c506 in x86_dr_stopped_data_address > (state=0xec6da0e4010, addr_p=0x7f7ffffbde70) at > ../../gdb/nat/x86-dregs.c:608 > 608 status = x86_dr_low_get_status (); > > > I tried to step-in debug it, and found it seems to access an invalid > function address: > > (top-gdb) display /i $pc > 1: x/i $pc > => 0x76de4af4f5 <x86_dr_stopped_data_address(x86_debug_reg_state*, > unsigned long*)+37>: > mov 0x394874(%rip),%r12 # 0x76de843d70 > (top-gdb) ni > 0x00000076de4af4fc 608 status = x86_dr_low_get_status (); > 1: x/i $pc > => 0x76de4af4fc <x86_dr_stopped_data_address(x86_debug_reg_state*, > unsigned long*)+44>: mov 0x18(%r12),%r11 > (top-gdb) > 0x00000076de4af501 608 status = x86_dr_low_get_status (); > 1: x/i $pc > => 0x76de4af501 <x86_dr_stopped_data_address(x86_debug_reg_state*, > unsigned long*)+49>: callq 0x76de28f150 <__llvm_retpoline_r11> > (top-gdb) > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () > 1: x/i $pc > => 0x0: <error: Cannot access memory at address 0x0> > > I checked the source code, but can't figure out the reasons. Anyone > can give some clues? Thanks very much in advance! > > Best Regards > Nan Xiao > The line where you are stopped at is nat/x86-dregs.c:608, which is: status = x86_dr_low_get_status (); x86_dr_low_get_status is actually a macro defined to: #define x86_dr_low_get_status() (x86_dr_low.get_status ()) So try to print "x86_dr_low.get_status", I expected that we will see 0 / NULL. This callback is probably supposed to get set in _initialize_x86_bsd_nat: void _initialize_x86_bsd_nat () { #ifdef HAVE_PT_GETDBREGS x86_dr_low.set_control = x86bsd_dr_set_control; x86_dr_low.set_addr = x86bsd_dr_set_addr; x86_dr_low.get_addr = x86bsd_dr_get_addr; x86_dr_low.get_status = x86bsd_dr_get_status; x86_dr_low.get_control = x86bsd_dr_get_control; x86_set_debug_register_length (sizeof (void *)); #endif /* HAVE_PT_GETDBREGS */ } However, this assignment is guarded by HAVE_PT_GETDBREGS. Could you look into your gdb/config.h, what is the value of HAVE_PT_GETDBREGS? If it's indeed undef'ed, can you look into your config.log, to see how configure came to the conclusion that you don't have that feature? It would also be good to confirm that this function (_initialize_x86_bsd_nat) is called at startup like it's supposed to. This can be done by adding a printf in it, if you are unable to use gdb on itself. Simon ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The newest gdb 8.3 crash on OpenBSD 2020-01-30 4:21 ` Simon Marchi @ 2020-02-01 10:47 ` Nan Xiao 2020-02-03 17:00 ` Simon Marchi 0 siblings, 1 reply; 5+ messages in thread From: Nan Xiao @ 2020-02-01 10:47 UTC (permalink / raw) To: Simon Marchi; +Cc: gdb Hi Simon, Thanks very much for your reply! Yes, you are correct! After checking gdb/config.h, I found all ptrace related macros are undefined: /* Define if sys/ptrace.h defines the PTRACE_GETFPXREGS request. */ /* #undef HAVE_PTRACE_GETFPXREGS */ /* Define if sys/ptrace.h defines the PTRACE_GETREGS request. */ /* #undef HAVE_PTRACE_GETREGS */ /* Define to 1 if you have the <ptrace.h> header file. */ /* #undef HAVE_PTRACE_H */ /* Define if sys/ptrace.h defines the PT_GETDBREGS request. */ /* #undef HAVE_PT_GETDBREGS */ /* Define if sys/ptrace.h defines the PT_GETXMMREGS request. */ /* #undef HAVE_PT_GETXMMREGS */ I checked the header files, there is no /usr/include/ptrace.h. There is /usr/include/sys/ptrace.h, but the real definitions (such as PT_GETREGS, PT_SETREGS, etc) are in system related header files. E.g., in my OS, it is in /usr/include/amd64/ptrace.h. I checked OpenBSD's gdb port (gdb 7.12.1, http://openports.se/devel/gdb), it seems I need more tweak to make gdb work on OpenBSD, not as simple as just "configure" and "make". Anyway, thanks very much again for your time and help! Best Regards Nan Xiao On Thu, Jan 30, 2020 at 12:21 PM Simon Marchi <simark@simark.ca> wrote: > > On 2020-01-29 12:44 a.m., Nan Xiao wrote: > > Hi gdb community, > > > > Greeting from me! > > > > I am building the newest gdb 8.3 on OpenBSD 6.6 server (Virtual > > machine, amd64). The build is OK, but the gdb will crash when I tried > > to use it to debug program: > > > > (gdb) bt > > #0 0x0000000000000000 in ?? () > > #1 0x00000ec41fa1c506 in x86_dr_stopped_data_address > > (state=0xec6da0e4010, addr_p=0x7f7ffffbde70) at > > ../../gdb/nat/x86-dregs.c:608 > > #2 0x00000ec41fa1c7a3 in x86_dr_stopped_by_watchpoint > > (state=0xec6da0e4010) at ../../gdb/nat/x86-dregs.c:650 > > #3 0x00000ec41f82ae47 in > > x86_nat_target<obsd_nat_target>::stopped_by_watchpoint > > (this=0xec6da0e4010) at ../../gdb/x86-nat.h:100 > > #4 0x00000ec41f84ff71 in watchpoints_triggered (ws=<optimized out>) > > at ../../gdb/breakpoint.c:4727 > > #5 0x00000ec41f9ccb70 in handle_signal_stop (ecs=0x7f7ffffbe2f0) at > > ../../gdb/infrun.c:5605 > > #6 0x00000ec41f9c1eeb in handle_inferior_event (ecs=0x7f7ffffbe2f0) > > at ../../gdb/infrun.c:5178 > > #7 0x00000ec41f9c329b in fetch_inferior_event (client_data=<optimized > > out>) at ../../gdb/infrun.c:3753 > > #8 0x00000ec41f95ce59 in gdb_do_one_event () at ../../gdb/event-loop.c:1064 > > #9 0x00000ec41f95d42d in start_event_loop () at ../../gdb/event-loop.c:371 > > #10 0x00000ec41f9f3392 in captured_command_loop () at ../../gdb/main.c:331 > > #11 0x00000ec41f9f2e13 in captured_main (data=<optimized out>) at > > ../../gdb/main.c:1182 > > #12 gdb_main (args=<optimized out>) at ../../gdb/main.c:1198 > > #13 0x00000ec41f7fc378 in main (argc=<optimized out>, > > argv=0x7f7ffffbde70) at ../../gdb/gdb.c:32 > > (gdb) frame 1 > > #1 0x00000ec41fa1c506 in x86_dr_stopped_data_address > > (state=0xec6da0e4010, addr_p=0x7f7ffffbde70) at > > ../../gdb/nat/x86-dregs.c:608 > > 608 status = x86_dr_low_get_status (); > > > > > > I tried to step-in debug it, and found it seems to access an invalid > > function address: > > > > (top-gdb) display /i $pc > > 1: x/i $pc > > => 0x76de4af4f5 <x86_dr_stopped_data_address(x86_debug_reg_state*, > > unsigned long*)+37>: > > mov 0x394874(%rip),%r12 # 0x76de843d70 > > (top-gdb) ni > > 0x00000076de4af4fc 608 status = x86_dr_low_get_status (); > > 1: x/i $pc > > => 0x76de4af4fc <x86_dr_stopped_data_address(x86_debug_reg_state*, > > unsigned long*)+44>: mov 0x18(%r12),%r11 > > (top-gdb) > > 0x00000076de4af501 608 status = x86_dr_low_get_status (); > > 1: x/i $pc > > => 0x76de4af501 <x86_dr_stopped_data_address(x86_debug_reg_state*, > > unsigned long*)+49>: callq 0x76de28f150 <__llvm_retpoline_r11> > > (top-gdb) > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x0000000000000000 in ?? () > > 1: x/i $pc > > => 0x0: <error: Cannot access memory at address 0x0> > > > > I checked the source code, but can't figure out the reasons. Anyone > > can give some clues? Thanks very much in advance! > > > > Best Regards > > Nan Xiao > > > > The line where you are stopped at is nat/x86-dregs.c:608, which is: > > status = x86_dr_low_get_status (); > > x86_dr_low_get_status is actually a macro defined to: > > #define x86_dr_low_get_status() (x86_dr_low.get_status ()) > > So try to print "x86_dr_low.get_status", I expected that we will see 0 / NULL. > > This callback is probably supposed to get set in _initialize_x86_bsd_nat: > > void > _initialize_x86_bsd_nat () > { > #ifdef HAVE_PT_GETDBREGS > x86_dr_low.set_control = x86bsd_dr_set_control; > x86_dr_low.set_addr = x86bsd_dr_set_addr; > x86_dr_low.get_addr = x86bsd_dr_get_addr; > x86_dr_low.get_status = x86bsd_dr_get_status; > x86_dr_low.get_control = x86bsd_dr_get_control; > x86_set_debug_register_length (sizeof (void *)); > #endif /* HAVE_PT_GETDBREGS */ > } > > However, this assignment is guarded by HAVE_PT_GETDBREGS. Could you look into > your gdb/config.h, what is the value of HAVE_PT_GETDBREGS? If it's indeed undef'ed, > can you look into your config.log, to see how configure came to the conclusion that > you don't have that feature? > > It would also be good to confirm that this function (_initialize_x86_bsd_nat) is called > at startup like it's supposed to. This can be done by adding a printf in it, if you are > unable to use gdb on itself. > > Simon ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The newest gdb 8.3 crash on OpenBSD 2020-02-01 10:47 ` Nan Xiao @ 2020-02-03 17:00 ` Simon Marchi 2020-02-04 9:20 ` Nan Xiao 0 siblings, 1 reply; 5+ messages in thread From: Simon Marchi @ 2020-02-03 17:00 UTC (permalink / raw) To: Nan Xiao; +Cc: gdb On 2020-02-01 5:47 a.m., Nan Xiao wrote: > Hi Simon, > > Thanks very much for your reply! > > Yes, you are correct! After checking gdb/config.h, I found all ptrace > related macros are undefined: > > /* Define if sys/ptrace.h defines the PTRACE_GETFPXREGS request. */ > /* #undef HAVE_PTRACE_GETFPXREGS */ > > /* Define if sys/ptrace.h defines the PTRACE_GETREGS request. */ > /* #undef HAVE_PTRACE_GETREGS */ > > /* Define to 1 if you have the <ptrace.h> header file. */ > /* #undef HAVE_PTRACE_H */ > > /* Define if sys/ptrace.h defines the PT_GETDBREGS request. */ > /* #undef HAVE_PT_GETDBREGS */ > > /* Define if sys/ptrace.h defines the PT_GETXMMREGS request. */ > /* #undef HAVE_PT_GETXMMREGS */ > > I checked the header files, there is no /usr/include/ptrace.h. There > is /usr/include/sys/ptrace.h, but the real definitions (such as > PT_GETREGS, PT_SETREGS, etc) are in system related header files. E.g., > in my OS, it is in /usr/include/amd64/ptrace.h. I checked OpenBSD's > gdb port (gdb 7.12.1, http://openports.se/devel/gdb), it seems I need > more tweak to make gdb work on OpenBSD, not as simple as just > "configure" and "make". > > Anyway, thanks very much again for your time and help! > > Best Regards > > Nan Xiao Ok, it would be nice if GDB worked, instead of crashed, with a simple ./configure && make on OpenBSD. If you manage to make it work, please consider sending a patch so that other users don't bump into this problem! Simon ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The newest gdb 8.3 crash on OpenBSD 2020-02-03 17:00 ` Simon Marchi @ 2020-02-04 9:20 ` Nan Xiao 0 siblings, 0 replies; 5+ messages in thread From: Nan Xiao @ 2020-02-04 9:20 UTC (permalink / raw) To: Simon Marchi; +Cc: gdb Hi Simon, Got it, thanks again for your help! Best Regards Nan Xiao On Tue, Feb 4, 2020 at 1:00 AM Simon Marchi <simark@simark.ca> wrote: > > On 2020-02-01 5:47 a.m., Nan Xiao wrote: > > Hi Simon, > > > > Thanks very much for your reply! > > > > Yes, you are correct! After checking gdb/config.h, I found all ptrace > > related macros are undefined: > > > > /* Define if sys/ptrace.h defines the PTRACE_GETFPXREGS request. */ > > /* #undef HAVE_PTRACE_GETFPXREGS */ > > > > /* Define if sys/ptrace.h defines the PTRACE_GETREGS request. */ > > /* #undef HAVE_PTRACE_GETREGS */ > > > > /* Define to 1 if you have the <ptrace.h> header file. */ > > /* #undef HAVE_PTRACE_H */ > > > > /* Define if sys/ptrace.h defines the PT_GETDBREGS request. */ > > /* #undef HAVE_PT_GETDBREGS */ > > > > /* Define if sys/ptrace.h defines the PT_GETXMMREGS request. */ > > /* #undef HAVE_PT_GETXMMREGS */ > > > > I checked the header files, there is no /usr/include/ptrace.h. There > > is /usr/include/sys/ptrace.h, but the real definitions (such as > > PT_GETREGS, PT_SETREGS, etc) are in system related header files. E.g., > > in my OS, it is in /usr/include/amd64/ptrace.h. I checked OpenBSD's > > gdb port (gdb 7.12.1, http://openports.se/devel/gdb), it seems I need > > more tweak to make gdb work on OpenBSD, not as simple as just > > "configure" and "make". > > > > Anyway, thanks very much again for your time and help! > > > > Best Regards > > > > Nan Xiao > > Ok, it would be nice if GDB worked, instead of crashed, with a simple ./configure && make on > OpenBSD. If you manage to make it work, please consider sending a patch so that other users > don't bump into this problem! > > Simon ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-02-04 9:20 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-29 5:44 The newest gdb 8.3 crash on OpenBSD Nan Xiao 2020-01-30 4:21 ` Simon Marchi 2020-02-01 10:47 ` Nan Xiao 2020-02-03 17:00 ` Simon Marchi 2020-02-04 9:20 ` Nan Xiao
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).