PRs for manpage 'gdb(1)'
This is an experimental report containing PRs for manpage 'gdb(1)' as of Fri May 30 07:37:14 2014 UTC. See notes.
PRs for manpage 'gdb(1)':
| S | Submitted | Tracker | Resp. | Description |
|---|---|---|---|---|
| o | 2011/06/11 | gnu/157755 | [patch] gdb(1) hardware watchpoints do not work correctly in multi-threaded programs | |
| o | 2010/12/03 | gnu/152808 | gdb(1) crash on exit | |
| o | 2010/11/24 | bin/152546 | gdb(1): internal-error: fbsd_thread_new_objfile: Assertion `proc_handle.pid == 0' failed. | |
| o | 2009/04/16 | kern/133775 | [patch] gdb(1) debugscripts: fix proc address print in ps macros | |
| o | 2008/10/22 | gnu/128284 | gdb(1) segfaults | |
| o | 2008/06/25 | gnu/124970 | gdb(1): gdb crashes after setting hardware watchpoint | |
| o | 2008/01/28 | bin/120095 | gdb(1) fails to catch signals when threading is involved | |
| o | 2007/03/28 | gnu/110971 | gdb(1) crashes | |
| o | 2007/03/09 | bin/110146 | joerg | [patch] [request] Allow arbitrary gdb(1) options to bypass kgdb |
| o | 2004/07/17 | bin/69164 | gdb(1) amd64: coredump while debugging a core file. | |
| o | 2004/07/06 | bin/68727 | gdb(1) coredumps after recent CURRENT upgrade | |
| o | 2003/02/11 | bin/48183 | [patch] gdb(1) on a core(5)-file from a threaded process can't see | |
| o | 2001/12/26 | bin/33182 | gdb(1) seg faults when given handle SIGALRM nopass for threaded app | |
| o | 2001/05/13 | bin/27306 | [patch] hw watchpoints work unreliable under gdb(1) | |
| o | 2001/01/04 | bin/24066 | gdb(1) can't detach from programs linked with libc_r |
Notes
GNATS has no finer-grained categorization than 'kern', 'bin', 'ports', and so forth. To augment this, the bugmeisters have adopted the convention of adding '<name>(<section>)' to the Synopsis field. Consider this a prototype of a better search function.
Please give feedback on this report to linimon@FreeBSD.org. Thanks.
Bugs can be in one of several states:
- o - open
- A problem report has been submitted, no sanity checking performed.
- a - analyzed
- The problem is understood and a solution is being sought.
- f - feedback
- Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution.
- p - patched
- A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open.
- r - repocopy
- The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion.
- s - suspended
- The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended.
- c - closed
- A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned.