PRs for tag 'dtrace'
This is an experimental report containing PRs for tag 'dtrace' as of 3-8-2014. GNATS has no finer-grained categorization than 'kern', 'bin', 'ports', and so forth. To augment this, the bugmeisters have adopted the convention of adding '[<tagname>]' to the Synopsis field. Consider this a prototype of a better search function.
This report is generated statically.
Please give feedback on this report to linimon@FreeBSD.org. Thanks.
PRs for tag 'dtrace':
|p||2014/02/25||kern/187027||markj||[dtrace] [patch] Make DTrace DOF limits configurable|
|p||2014/02/16||kern/186821||markj||[dtrace] [patch] dtrace_dof_init() crashes when there is no probes section|
|o||2013/12/30||kern/185290||markj||[dtrace] Dtrace does not work on -stable/10|
|o||2013/11/19||kern/184085||markj||[dtrace] process crash when dtrace is run: dtrace -n pid<PID>:::entry|
|p||2013/01/30||kern/175705||markj||[dtrace] "panic: process not held" when invoking userland dtrace with INVARIANTS enabled|
|o||2012/11/08||bin/173484||gnn||[feature request] [dtrace] the current implementation requires kernel being uncompressed|
|p||2012/09/06||kern/171360||gnn||[patch][dtrace] the fasttrap fork handler recurses on the child proc mutex|
|o||2012/07/05||kern/169657||gnn||[dtrace] name clash between dtrace and geom.h|
|o||2012/06/24||kern/169379||gnn||[dtrace] [patch] dtrace's timestamp variable is unreliable when the cpu goes into C3 state|
|o||2012/06/23||kern/169350||gnn||[dtrace] Extraneous output when tracing writes with output redirect to a file|
|f||2012/06/14||kern/169080||markj||[dtrace] DTrace broken for simple user land program|
|p||2012/04/13||kern/166925||gnn||[dtrace] lockstat provider only works in files that #include "opt_kdtrace.h"|
|o||2012/04/13||kern/166924||gnn||[dtrace] deferred DTrace probes never match if executable linked with -E|
|f||2012/04/13||kern/166923||gnn||[dtrace] kernel trap 12 with interrupts disabled (not a panic!?)|
|p||2012/04/13||kern/166922||gnn||[dtrace] Wildcarded dtrace probe names not always working|
|o||2012/04/13||kern/166919||gnn||[dtrace] If dtrace(1) crashes while attached to a process, the process is left in a weird state|
|o||2012/04/13||kern/166918||gnn||[dtrace] USDT probes not cleaned up when process exits uncleanly|
|o||2012/02/25||kern/165479||rstone||[dtrace] [lor] LOR in Userland Dtrace(fasttrap_provs.fth_table[i].ftb_mtx/dtrace_provider_lock)|
|p||2011/07/19||kern/159046||rwatson||[dtrace] [patch] dtrace library is linked with a wrong flags on -CURRENT|
|f||2011/07/18||kern/159013||gnn||[dtrace] kldunload dtraceall crashing if userland dtrace provider is in use|
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.