- Rather than assuming that a process is listening on 127.0.0.1:22, use
nc(1) to find an available port and bind to it for the duration of the
test.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
../common/libzfs_import.c, line 1077, function zpool_open_func
illumos/illumos-gate@bd0f709169
Author: Andrew Stormont <andyjstormont@gmail.com>
MFC after: 13 days
0. For spin events report time spent spinning, not a loop count.
While loop count is much easier and cheaper to obtain it is hard
to reason about the reported numbers, espcially for adaptive locks
where both spinning and sleeping can happen.
So, it's better to compare apples and apples.
1. Teach lockstat about FreeBSD rw locks.
This is done in part by changing the corresponding probes
and in part by changing what probes lockstat should expect.
2. Teach lockstat that rw locks are adaptive and can spin on FreeBSD.
3. Report lock acquisition events for successful rw try-lock operations.
4. Teach lockstat about FreeBSD sx locks.
Reporting of events for those locks completely mirrors
rw locks.
5. Report spin and block events before acquisition event.
This is behavior documented for the upstream, so it makes sense to stick
to it. Note that because of FreeBSD adaptive lock implementations
both the spin and block events may be reported for the same acquisition
while the upstream reports only one of them.
Differential Revision: https://reviews.freebsd.org/D2727
Reviewed by: markj
MFC after: 17 days
Relnotes: yes
Sponsored by: ClusterHQ
The "depends_on module" pragma can be used to declare a dependency on a
DTrace module, which for kernel probes corresponds to a KLD. Such
dependencies cannot be checked if the KLD is compiled into the kernel.
Therefore, allow a module dependency to be satisfied if either a kernel
module or a KLD with the specified name is loaded.
Differential Revision: https://reviews.freebsd.org/D2653
Reviewed by: gnn, rpaulo
Reported by: gnn
return an error if one of the depends_on directives in a library is not
satisfied. In this case, libdtrace is supposed to ignore the library and
carry on. However, the remainder of the library may still be buffered by
the lexer, causing libdtrace to erroneously continue processing it on the
next call to yyparse(). Fix this by explicitly flushing the input buffer
each time the compiler state is reset.
MFC after: 3 weeks
list of pending dynamic type definitions, a match on the type name is not
sufficient - we need to compare the type encodings as well. For example,
bitfields have their own distinct type definitions which share the name of
the underlying integer type, and these types aren't generally
interchangeable.
This bug was causing the following libdtrace error when attempting to trace
the th_flags member of a struct tcphdr:
cg: bad field: off 104 type <32877> bits 539620016
Reported by: rwatson
MFC after: 3 weeks
The format of these pages is somewhat experimental, so they may be subject
to further tweaking.
Differential Revision: https://reviews.freebsd.org/D2170
Reviewed by: bcr, rpaulo
MFC after: 2 weeks
Passing "-x lazyload" to dtrace -G during compilation causes dtrace(1) to
not link drti.o into the output object file, so the USDT probes are not created
during process startup. Instead, dtrace(1) will automatically discover and
create probes on the process' behalf when attaching.
Differential Revision: https://reviews.freebsd.org/D2203
Reviewed by: rpaulo
MFC after: 1 month
ctf_add_type() first performs a by-name lookup of the type in the
destination container. If this lookup returns a forward declaration for an
enum, struct, or union, reset dst_type back to CTF_ERR, indicating that the
source type is not in fact present in the destination container. This
ensures that ctf_add_type() will also search the destination container's
dynamic type list for the source type.
Without this change, a pair of mutually recursive struct definitions could
cause infinite recursion in ctf_add_type() if the destination container
only contained forward declarations for the struct types: ctf_add_type()
recursively calls itself on each struct member's type, and the forward
declarations meant that the dynamic type list search would be skipped.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
indicates the range of type indices which have been committed to the
container by ctf_update(). However, the top bit of the dtd_type field is
not part of the type index; rather, it is a flag used to indicate that the
corresponding CTF container is a parent. This is why the maximum CTF type
index is 2^15 - 1 rather than 2^16 - 1. Therefore, this flag must be masked
off (using the CTF_TYPE_TO_INDEX macro) when comparing a type index with the
ctf_dtoldid field of a container.
This bug was causing libctf to erroneously free committed type definitions
in ctf_discard(). libdtrace holds some references to such types, resulting
in a use-after-free.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
we end up skipping a dynamic type because it has already been committed to
the container, we would previously either set the loop variable to an
uninitialized local variable, or set it to itself, resulting in an infinite
loop.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
This merge is effectively a no-op since parts of it are already present
in FreeBSD, and the rest is incorrect since gelf_newehdr(3) and
gelf_newphdr(3) return pointers on FreeBSD rather than integers.
Illumos issue:
5589 improper use of NULL in tools/ctf
MFC after: 3 days
probes to userland programs and libraries without also needing to link
libelf.
dtrace -G places the __SUNW_dof symbol at the beginning of the DOF (DTrace
probe and provider metdata) section in the generated object file; drti.o
now just uses this symbol to locate the section. A complication occurs
when multiple dtrace-generated object files are linked together, since the
__SUNW_dof symbol defined in each file is global. This is handled by
using objcopy(1) to convert __SUNW_dof to a local symbol once drti.o has
been linked with the generated object file. Upstream, this is done using a
linker feature not present in GNU ld.
Differential Revision: https://reviews.freebsd.org/D1757
Reviewed by: rpaulo
MFC after: 1 month
Relnotes: yes
the test harness. This is a problem in many of the *.ksh test scripts as
well, but those scripts are executed using a shell whose path is specified
in dtest.pl, so there's no need to modify them.
MFC after: 1 week
the behaviour for averages, and fixes a crash that can occur when attempting
to print a stddev aggregation containing no elements:
dtrace:::BEGIN { @ = stddev(0); clear(@); printa("%@d", @); }
PR: 197260
MFC after: 2 week
* Avoid hard-coding program paths.
* Use -x when searching for oneself in ps(1) output.
* Use the correct keyword (egid instead of pgid) in tst.egid.ksh.
MFC after: 1 week
* Avoid hard-coding program paths, except when it's necessary in order to
override the use of a shell builtin.
* Translate struct proc through psinfo_t so that we can access process
arguments via the pr_psargs field of psinfo_t.
* Replace uses of pstop and prun with kill(1).
MFC after: 1 week
which causes dtrace(1) to run the C preprocessor on input scripts before
executing them. Suppress some warnings emitted by the preprocessor which are
confusing the DTrace lexer tests.
MFC after: 1 week
