7.3 is broken on FreeBSD

7.3 is broken on FreeBSD

[Yuri]

When I tried to debug something large (thunderbird built with DEBUG 
option) on FreeBSD-8.2 amd64 gdb73 crashed (SEGV).

Also, gdb7.2 has a long standing bug on FreeBSD that it fails with: 
"Invalid selected thread." error on multithreaded applications.

Yuri

Re: 7.3 is broken on FreeBSD

[Tom Tromey]

>>>>> "yuri" == yuri  <yuri@rawbw.com> writes:

yuri> When I tried to debug something large (thunderbird built with DEBUG
yuri> option) on FreeBSD-8.2 amd64 gdb73 crashed (SEGV).

This isn't enough information.
Can you get a stack trace from gdb?

yuri> Also, gdb7.2 has a long standing bug on FreeBSD that it fails with:
yuri> "Invalid selected thread." error on multithreaded applications.

Is it still a bug in 7.3?

Tom

Re: 7.3 is broken on FreeBSD

[Yuri]

On 07/06/2011 13:59, Tom Tromey wrote:
> yuri>  When I tried to debug something large (thunderbird built with DEBUG
> yuri>  option) on FreeBSD-8.2 amd64 gdb73 crashed (SEGV).
>
> This isn't enough information.
> Can you get a stack trace from gdb?

Here is the debugging session log, debugging gdb-7.3 running debug 
thunderbird with gdb-7.2:

[yuri@eagle /home/yuri]$ LD_LIBRARY_PATH=/usr/local/lib/thunderbird 
gdb72 /usr/local/gdb-7.3/bin/gdb
GNU gdb (GDB) 7.2 [GDB v7.2 for FreeBSD]
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd8.2".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/gdb-7.3/bin/gdb...done.
(gdb) r /usr/local/lib/thunderbird/thunderbird-bin
Starting program: /usr/local/gdb-7.3/bin/gdb 
/usr/local/lib/thunderbird/thunderbird-bin
[New LWP 101940]
[New Thread 8018041c0 (LWP 101940)]
GNU gdb (GDB) 7.2.90.20110706-cvs
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-freebsd8.2".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/lib/thunderbird/thunderbird-bin...done.
(gdb) c
The program is not being run.
(gdb) r
Starting program: /usr/local/lib/thunderbird/thunderbird-bin

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8018041c0 (LWP 101940)]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000000066ceb8 in i386_stopped_data_address (ops=0xa749a0, 
addr_p=0x7fffffffd498) at i386-nat.c:563
#2  0x000000000066cfce in i386_stopped_by_watchpoint () at i386-nat.c:596
#3  0x00000000005068d5 in watchpoints_triggered (ws=0x7fffffffd8d0) at 
breakpoint.c:3652
#4  0x000000000056e55f in handle_inferior_event (ecs=0x7fffffffd8b0) at 
infrun.c:3795
#5  0x000000000056bcd3 in wait_for_inferior (treat_exec_as_sigtrap=0) at 
infrun.c:2610
#6  0x000000000056afa3 in proceed (addr=34365003584, 
siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:2136
#7  0x0000000000563d70 in run_command_1 (args=0x0, from_tty=1, 
tbreak_at_main=0) at infcmd.c:600
#8  0x0000000000563db0 in run_command (args=0x0, from_tty=1) at infcmd.c:610
#9  0x00000000004bae44 in do_cfunc (c=0x8018daa00, args=0x0, from_tty=1) 
at ./cli/cli-decode.c:67
#10 0x00000000004bde25 in cmd_func (cmd=0x8018daa00, args=0x0, 
from_tty=1) at ./cli/cli-decode.c:1777
#11 0x0000000000459b84 in execute_command (p=0x801813081 "", from_tty=1) 
at top.c:428
#12 0x0000000000587c4e in command_handler (command=0x801813080 "") at 
event-top.c:499
#13 0x0000000000588232 in command_line_handler (rl=0x801816118 "r") at 
event-top.c:704
#14 0x000000000069ee60 in rl_callback_read_char () at callback.c:205
#15 0x00000000005872a1 in rl_callback_read_char_wrapper 
(client_data=0x0) at event-top.c:177
#16 0x0000000000587b11 in stdin_event_handler (error=0, client_data=0x0) 
at event-top.c:434
#17 0x0000000000586228 in handle_file_event (data=...) at event-loop.c:831
#18 0x0000000000585872 in process_event () at event-loop.c:402
#19 0x000000000058595b in gdb_do_one_event (data=0x0) at event-loop.c:467
#20 0x000000000057feef in catch_errors (func=0x585890 
<gdb_do_one_event>, func_args=0x0, errstring=0x7b6e43 "", mask=6) at 
exceptions.c:521
#21 0x00000000004d3444 in tui_command_loop (data=0x0) at 
./tui/tui-interp.c:172
#22 0x00000000005806e7 in current_interp_command_loop () at interps.c:291
#23 0x000000000044eb11 in captured_command_loop (data=0x0) at ./main.c:228
#24 0x000000000057feef in catch_errors (func=0x44eb00 
<captured_command_loop>, func_args=0x0, errstring=0x799577 "", mask=6) 
at exceptions.c:521
#25 0x000000000044faeb in captured_main (data=0x7fffffffe000) at 
./main.c:936
#26 0x000000000057feef in catch_errors (func=0x44eb50 <captured_main>, 
func_args=0x7fffffffe000, errstring=0x799577 "", mask=6) at exceptions.c:521
#27 0x000000000044fb71 in gdb_main (args=0x7fffffffe000) at ./main.c:945
#28 0x000000000044e838 in main (argc=2, argv=0x7fffffffe078) at gdb.c:35
(gdb)

>
> yuri>  Also, gdb7.2 has a long standing bug on FreeBSD that it fails with:
> yuri>  "Invalid selected thread." error on multithreaded applications.
>
> Is it still a bug in 7.3?
>

Not sure, because of the first problem.

Yuri

Re: 7.3 is broken on FreeBSD

[Joel Brobecker]

> Here is the debugging session log, debugging gdb-7.3 running debug
> thunderbird with gdb-7.2:
[...]
> (gdb) r
> Starting program: /usr/local/lib/thunderbird/thunderbird-bin
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 8018041c0 (LWP 101940)]

Can you look at gdb/config.in in the build directory, and tell
me if the following macro is defined?

        HAVE_PT_GETDBREGS

It looks like there definitely is a weakness that leaves the
i386_dr_low structure unset if that macro is not defined. But
as far as I can tell, it's working just great for me.

The code in question is _initialize_i386fbsd_nat:

   #ifdef HAVE_PT_GETDBREGS
   
     i386_use_watchpoints (t);
   
     i386_dr_low.set_control = i386bsd_dr_set_control;
     i386_dr_low.set_addr = i386bsd_dr_set_addr;
     i386_dr_low.reset_addr = i386bsd_dr_reset_addr;
     i386_dr_low.get_status = i386bsd_dr_get_status;
     i386_set_debug_register_length (4);
   
   #endif /* HAVE_PT_GETDBREGS */

I don't have FreeBSD 8.2 lying around, can you see if
PT_GETDBREGS is defined in /usr/include/sys/ptrace.h?
As fra as I can tell, it's still available in FreeBSD 8.1.

In the meantime, I think we'll process with the first pre-release,
with a question mark on FreeBSD 8.2. We might release with 8.2
being known to be broken, we'll see when we're ready to make
the release whether to wait for a fix or not (just to be clear,
I am not planning on working on this, I won't even have time).

-- 
Joel

Re: 7.3 is broken on FreeBSD

[Yuri]

On 07/06/2011 15:42, Joel Brobecker wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 8018041c0 (LWP 101940)]
> Can you look at gdb/config.in in the build directory, and tell
> me if the following macro is defined?
>
>          HAVE_PT_GETDBREGS

I have #undef HAVE_PT_GETDBREGS


>
> It looks like there definitely is a weakness that leaves the
> i386_dr_low structure unset if that macro is not defined. But
> as far as I can tell, it's working just great for me.
>
> The code in question is _initialize_i386fbsd_nat:
>
>     #ifdef HAVE_PT_GETDBREGS
>
>       i386_use_watchpoints (t);
>
>       i386_dr_low.set_control = i386bsd_dr_set_control;
>       i386_dr_low.set_addr = i386bsd_dr_set_addr;
>       i386_dr_low.reset_addr = i386bsd_dr_reset_addr;
>       i386_dr_low.get_status = i386bsd_dr_get_status;
>       i386_set_debug_register_length (4);
>
>     #endif /* HAVE_PT_GETDBREGS */
>
> I don't have FreeBSD 8.2 lying around, can you see if
> PT_GETDBREGS is defined in /usr/include/sys/ptrace.h?


#define PT_GETDBREGS    37      /* get debugging registers */


Yuri

Re: 7.3 is broken on FreeBSD

[Joel Brobecker]

> >Program received signal SIGSEGV, Segmentation fault.
> >[Switching to Thread 8018041c0 (LWP 101940)]
> >Can you look at gdb/config.in in the build directory, and tell
> >me if the following macro is defined?
> >
> >         HAVE_PT_GETDBREGS
> 
> I have #undef HAVE_PT_GETDBREGS

That explains it why you get the SEGV...

> >I don't have FreeBSD 8.2 lying around, can you see if
> >PT_GETDBREGS is defined in /usr/include/sys/ptrace.h?
> 
> 
> #define PT_GETDBREGS    37      /* get debugging registers */

But that doesn't explain why it's undef'ed in your case. For that,
you're going to have to look inside the gdb/config.log file,
and search for PT_GETDBREGS.  It should tell you that the compilation
failed, what source file was used, and why it failed.

-- 
Joel

Re: 7.3 is broken on FreeBSD

[Yuri]

On 07/06/2011 15:55, Joel Brobecker wrote:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 8018041c0 (LWP 101940)]
>>> Can you look at gdb/config.in in the build directory, and tell
>>> me if the following macro is defined?
>>>
>>>          HAVE_PT_GETDBREGS
>> I have #undef HAVE_PT_GETDBREGS
> That explains it why you get the SEGV...
>
>
>>
>> #define PT_GETDBREGS    37      /* get debugging registers */
> But that doesn't explain why it's undef'ed in your case. For that,
> you're going to have to look inside the gdb/config.log file,
> and search for PT_GETDBREGS.  It should tell you that the compilation
> failed, what source file was used, and why it failed.
>

configure:13151: result: no
configure:13160: checking for PT_GETDBREGS
configure:13177: gcc -c -g -O2   conftest.c >&5
configure:13177: $? = 0
configure:13185: result: yes
configure:13194: checking for PT_GETXMMREGS
configure:13211: gcc -c -g -O2   conftest.c >&5
conftest.c: In function 'main':
conftest.c:197: error: 'PT_GETXMMREGS' undeclared (first use in this 
function)
conftest.c:197: error: (Each undeclared identifier is reported only once
conftest.c:197: error: for each function it appears in.)
configure:13211: $? = 1

Yuri

Re: 7.3 is broken on FreeBSD

[Joel Brobecker]

> configure:13151: result: no
> configure:13160: checking for PT_GETDBREGS
> configure:13177: gcc -c -g -O2   conftest.c >&5
> configure:13177: $? = 0
> configure:13185: result: yes

Something does NOT make sense to me. If it says 'yes', then
I don't understand why HAVE_PT_GETDBREGS is not defined.
Here is the configure code:

    | AC_MSG_CHECKING(for PT_GETDBREGS)
    | AC_CACHE_VAL(gdb_cv_have_pt_getdbregs,
    | [AC_TRY_COMPILE([#include <sys/types.h>
    | #include <sys/ptrace.h>],
    |                 [PT_GETDBREGS;],
    |                 [gdb_cv_have_pt_getdbregs=yes],
    |                 [gdb_cv_have_pt_getdbregs=no])])
    | AC_MSG_RESULT($gdb_cv_have_pt_getdbregs)
    | if test $gdb_cv_have_pt_getdbregs = yes; then
    |   AC_DEFINE(HAVE_PT_GETDBREGS, 1,
    |   [Define if sys/ptrace.h defines the PT_GETDBREGS request.])
    | fi

Could something be wrong with your setup? Did you configure from
scratch, or did you do some incremental builds? I have no idea
and I don't know how to help you further on this.

> configure:13194: checking for PT_GETXMMREGS
> configure:13211: gcc -c -g -O2   conftest.c >&5
> conftest.c: In function 'main':
> conftest.c:197: error: 'PT_GETXMMREGS' undeclared (first use in this
> function)
> conftest.c:197: error: (Each undeclared identifier is reported only once
> conftest.c:197: error: for each function it appears in.)
> configure:13211: $? = 1

This part has no effect on the FreeBSD port.

-- 
Joel

Re: 7.3 is broken on FreeBSD

[Yuri]

On 07/06/2011 16:24, Joel Brobecker wrote:
> This part has no effect on the FreeBSD port. 


I see, you meant gdb/config.h, HAVE_PT_GETDBREGS is defined theer:
#define HAVE_PT_GETDBREGS 1

Yuri

Re: 7.3 is broken on FreeBSD

[Joel Brobecker]

> I see, you meant gdb/config.h, HAVE_PT_GETDBREGS is defined theer:
> #define HAVE_PT_GETDBREGS 1

So, we'd be back to square one: Why does GDB crash.  Looking at
the backtrace, it looks like it tried to make a call via a null
function pointer.

Since I can't reproduce, and I'm out of ideas of what might be
wrong, I'm afraid you'll have to debug this one.

-- 
Joel

Re: 7.3 is broken on FreeBSD

[Yuri]

On 07/06/2011 18:59, Joel Brobecker wrote:
>> I see, you meant gdb/config.h, HAVE_PT_GETDBREGS is defined theer:
>> #define HAVE_PT_GETDBREGS 1
> So, we'd be back to square one: Why does GDB crash.  Looking at
> the backtrace, it looks like it tried to make a call via a null
> function pointer.
>
> Since I can't reproduce, and I'm out of ideas of what might be
> wrong, I'm afraid you'll have to debug this one.
>

gdb-7.3 crashes on this line:
563       dr_status_mirror = i386_dr_low.get_status ();
(gdb) p i386_dr_low
$1 = {set_control = 0, set_addr = 0, reset_addr = 0, get_status = 0, 
unset_status = 0, debug_register_length = 0}
(gdb) p i386_dr_low.get_status ()

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(at 0x0x0) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb)


Yuri

Re: 7.3 is broken on FreeBSD

[Joel Brobecker]

> gdb-7.3 crashes on this line:
> 563       dr_status_mirror = i386_dr_low.get_status ();
> (gdb) p i386_dr_low
> $1 = {set_control = 0, set_addr = 0, reset_addr = 0, get_status = 0,
> unset_status = 0, debug_register_length = 0}

But i386_dr_low is supposed to be set at GDB startup by
_initialize_i386fbsd_nat:

    void
    _initialize_i386fbsd_nat (void)
    {
      struct target_ops *t;
    
      /* Add some extra features to the common *BSD/i386 target.  */
      t = i386bsd_target ();
    
    #ifdef HAVE_PT_GETDBREGS
    
      i386_use_watchpoints (t);
    
      i386_dr_low.set_control = i386bsd_dr_set_control;
      i386_dr_low.set_addr = i386bsd_dr_set_addr;
      i386_dr_low.reset_addr = i386bsd_dr_reset_addr;
      i386_dr_low.get_status = i386bsd_dr_get_status;
      i386_set_debug_register_length (4);
    
    #endif /* HAVE_PT_GETDBREGS */

Is this happening? And if yes, then who is overriding the value?
If not, why is it not happening, since you confirmed that 
HAVE_PT_GETDBREGS is defined.

-- 
Joel

Re: 7.3 is broken on FreeBSD

[Yuri]

On 07/06/2011 21:31, Joel Brobecker wrote:
>> gdb-7.3 crashes on this line:
>> 563       dr_status_mirror = i386_dr_low.get_status ();
>> (gdb) p i386_dr_low
>> $1 = {set_control = 0, set_addr = 0, reset_addr = 0, get_status = 0,
>> unset_status = 0, debug_register_length = 0}
> But i386_dr_low is supposed to be set at GDB startup by
> _initialize_i386fbsd_nat:
>
>      void
>      _initialize_i386fbsd_nat (void)
>      {
>        struct target_ops *t;
>
>        /* Add some extra features to the common *BSD/i386 target.  */
>        t = i386bsd_target ();
>
>      #ifdef HAVE_PT_GETDBREGS
>
>        i386_use_watchpoints (t);
>
>        i386_dr_low.set_control = i386bsd_dr_set_control;
>        i386_dr_low.set_addr = i386bsd_dr_set_addr;
>        i386_dr_low.reset_addr = i386bsd_dr_reset_addr;
>        i386_dr_low.get_status = i386bsd_dr_get_status;
>        i386_set_debug_register_length (4);
>
>      #endif /* HAVE_PT_GETDBREGS */
>
> Is this happening? And if yes, then who is overriding the value?
> If not, why is it not happening, since you confirmed that
> HAVE_PT_GETDBREGS is defined.
>

Instead _initialize_amd64fbsd_nat is called. I only see that i386_dr_low 
is being set in i386fbsd-nat.c.
Shouldn't there also be amd64_dr_low ?

Yuri

Re: 7.3 is broken on FreeBSD

[Tom Tromey]

>>>>> "yuri" == yuri  <yuri@rawbw.com> writes:

yuri> Instead _initialize_amd64fbsd_nat is called. I only see that
yuri> i386_dr_low is being set in i386fbsd-nat.c.
yuri> Shouldn't there also be amd64_dr_low ?

Or something like that, see amd64-linux-nat.c, which follows the i386
setup.  I don't know this area well but I guess either the port needs
more work, or there was a regression at some point.

Tom

Re: 7.3 is broken on FreeBSD

[Yuri]

On 07/06/2011 15:55, Joel Brobecker wrote:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 8018041c0 (LWP 101940)]
>>> Can you look at gdb/config.in in the build directory, and tell
>>> me if the following macro is defined?
>>>
>>>          HAVE_PT_GETDBREGS
>> I have #undef HAVE_PT_GETDBREGS
> That explains it why you get the SEGV...
>
>>> I don't have FreeBSD 8.2 lying around, can you see if
>>> PT_GETDBREGS is defined in /usr/include/sys/ptrace.h?
>>
>> #define PT_GETDBREGS    37      /* get debugging registers */
> But that doesn't explain why it's undef'ed in your case. For that,
> you're going to have to look inside the gdb/config.log file,
> and search for PT_GETDBREGS.  It should tell you that the compilation
> failed, what source file was used, and why it failed.
>

config.in has the old date, maybe that's why:
rw-r--r--  1 yuri  users  28240 Mar 17 06:19 gdb/config.in

I am not so familiar with autoconf/automake stuff. Is gdb/config.in 
supposed to be regenerated with configure run?
I just reconfigured from scratch and still have this.

Yuri