Bug 33182

Summary: gdb(1) seg faults when given handle SIGALRM nopass for threaded app
Product: Base System Reporter: Kip Macy <kip_macy>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: jhb
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Kip Macy 2001-12-26 05:40:01 UTC
      GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
(gdb) b main
Breakpoint 1 at 0x804864a: file alrmtest.c, line 55.
(gdb) r
Starting program: /usr/home/kmacy/netapp/dvlp/alrmtest 

Breakpoint 1, main () at alrmtest.c:55
55              sk_init_timer();
(gdb) list
50      }
51
52      int 
53      main() {
54              int i, j;
55              sk_init_timer();
56              while (1) {
57                      /*  useless assignment to demonstrate lack of progress */
58                      i = 0;
59                      /*  useless assignment to demonstrate lack of progress */
(gdb) n
56              while (1) {
(gdb) n

Program received signal SIGTRAP, Trace/breakpoint trap.
0x280f1150 in _thread_sys_sigprocmask () from /usr/lib/libc_r.so.4
(gdb) n
Single stepping until exit from function _thread_sys_sigprocmask, 
which has no line number information.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x280f1150 in _thread_sys_sigprocmask () from /usr/lib/libc_r.so.4
(gdb) handle SIGALRM nopass
Segmentation fault (core dumped)

How-To-Repeat: link app with libc_r
type handle SIGALRM nopass in gdb
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 2002-01-30 13:05:41 UTC
Responsible Changed
From-To: freebsd-bugs->mp

Over to maintainer.
Comment 2 Kip Macy 2002-02-09 23:54:33 UTC
I've already fixed this in the gdb51 port. I hope we can migrate to it
soon.
Comment 3 kmacy 2002-02-10 00:52:40 UTC
child_ops and procfs_ops don't implement to_notice_signals. If you look more
closely you'll notice that this is not needed.

diff /usr/src/gnu/usr.bin/binutils/gdb/freebsd-uthread.c.bak
/usr/src/gnu/usr.bin/binutils/gdb/freebsd-uthread.c
1116c1116
<   freebsd_uthread_ops.to_notice_signals = freebsd_uthread_notice_signals;
---
>   freebsd_uthread_ops.to_notice_signals = 0;
Comment 4 Marcel Moolenaar freebsd_committer freebsd_triage 2004-07-17 02:51:30 UTC
Responsible Changed
From-To: mp->marcel

Yet another PR that describes a gdb 4 bug.
Comment 5 Marcel Moolenaar freebsd_committer freebsd_triage 2011-02-21 18:50:24 UTC
Responsible Changed
From-To: marcel->freebsd-bugs

Assign back to the pool. I haven't been working on it and it's unlikely 
I will in the near future.
Comment 6 John Baldwin freebsd_committer freebsd_triage 2016-07-01 16:47:30 UTC
Even the ancient GDB in the base should have this fixed.