[DTrace-devel] [oracle/dtrace-utils] 6598c5: Use asprintf() to allocate strings
euloh
noreply at github.com
Tue Jan 27 18:14:27 UTC 2026
Branch: refs/heads/devel
Home: https://github.com/oracle/dtrace-utils
Commit: 6598c5d1e1a35e7287d09c559ddb25a0de704cd6
https://github.com/oracle/dtrace-utils/commit/6598c5d1e1a35e7287d09c559ddb25a0de704cd6
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2026-01-27 (Tue, 27 Jan 2026)
Changed paths:
M libdtrace/dt_link.c
M libdtrace/dt_prov_dtrace.c
Log Message:
-----------
Use asprintf() to allocate strings
Earlier patches have slowly replaced constructs like:
int len;
len = snprintf(NULL, 0, format, args) + 1;
buf = malloc(len);
snprintf(buf, len, format, args);
with the more compact:
asprintf(&buf, format, args);
Replace the remaining instances of the bulkier construct.
Note that dt_conf_init() continues to compute a buffer length and
allocate a buffer, since that buffer will be reused multiple times.
Further, dt_probe_tag() keeps its current form so that memory can be
allocated with alloca() to guard against memory leaks in the event that
ctf_add_typedef() fails.
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: cde47c01e36fc32e769e1d517487345c4b0efd75
https://github.com/oracle/dtrace-utils/commit/cde47c01e36fc32e769e1d517487345c4b0efd75
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2026-01-27 (Tue, 27 Jan 2026)
Changed paths:
M test/unittest/dtrace-util/tst.ListProbesFuncEmpty.r
M test/unittest/dtrace-util/tst.ListProbesFuncEmpty.sh
M test/unittest/dtrace-util/tst.ListProbesNameEmpty.r
M test/unittest/dtrace-util/tst.ListProbesNameEmpty.sh
Log Message:
-----------
test: Account for readahead tracepoints
Some tests check for empty probe descriptions. In some cases, the tests
relied on the absence of any read* modules.
However, some kernels can have "readahead" tracepoints. Tests expecting
no read* modules will therefore fail.
Change these tests to ask for readfoo* modules to ensure that the probe
descriptions will indeed find no probes.
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: ee89990bd8366d3d04e94db8c082936a6ef7d3ee
https://github.com/oracle/dtrace-utils/commit/ee89990bd8366d3d04e94db8c082936a6ef7d3ee
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2026-01-27 (Tue, 27 Jan 2026)
Changed paths:
M test/unittest/syscall/tst.entry.d
Log Message:
-----------
test: Increase syscall entry timeout
The run time for this test seems twice as long for aarch64 as for
x86_64. Further, the run time seems to have jumped significantly from
kernel 5.15 to 6.12 and then again to kernel 6.18. E.g.,
x86_64 aarch64
5.15 7 secs 18 secs
6.12 12 secs 33 secs
6.18 22 secs 54 secs
Looking at a run on the 6.18 aarch64 system, the time is basically
spent in the dtrace_close() call to dt_probe_detach_all(), which does:
for (prp = ...)
prp->prov->impl->detach(dtp, prp);
Then, dt_tp_probe_detach() calls dt_tp_detach(), which does:
close(tpp->fd);
This close() averages over 0.1 secs. For hundreds of syscall probes,
we get nearly a minute of run time, exceeding the default test timeout.
For the time being, increase the timeout on this test.
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: 2004f761031d7a5a62333d6644aa63b9a0f9cf1a
https://github.com/oracle/dtrace-utils/commit/2004f761031d7a5a62333d6644aa63b9a0f9cf1a
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2026-01-27 (Tue, 27 Jan 2026)
Changed paths:
M dtrace.spec
Log Message:
-----------
spec: testsuite: weakly pull in kernel-uek-tools to get perf
This prevents yum/dnf from pulling in the first kernel it finds, which
is often entirely wrong.
(This is obviously only applicable to OL and no other distro.)
Orabug: 38064413
Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Commit: 1a7c7e3005a0565fba750cb4b2947f414847a6a1
https://github.com/oracle/dtrace-utils/commit/1a7c7e3005a0565fba750cb4b2947f414847a6a1
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2026-01-27 (Tue, 27 Jan 2026)
Changed paths:
M libdtrace/mkvers
Log Message:
-----------
Revert "Support deeper version numbers (e.g. 2.0.4.x)"
This reverts commit 1898d098a582488c9de485a9b672f6b2929335ba.
The DTrace version numbering scheme only supports up to 3 digits in the
version number, and expanding this to 4 digits would require quite a lot
more changes.
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: 22023cdbf8b5a9c8bb03fd9bbbb57bd22fef5e26
https://github.com/oracle/dtrace-utils/commit/22023cdbf8b5a9c8bb03fd9bbbb57bd22fef5e26
Author: Eugene Loh <eugene.loh at oracle.com>
Date: 2026-01-27 (Tue, 27 Jan 2026)
Changed paths:
M NEWS
M dtrace.spec
M libdtrace/versions.list
Log Message:
-----------
Update NEWS and dtrace.spec for release 2.0.5
New release will be 2.0.5 instead of 2.0.4.1.
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Compare: https://github.com/oracle/dtrace-utils/compare/cb3df84987cb...22023cdbf8b5
To unsubscribe from these emails, change your notification settings at https://github.com/oracle/dtrace-utils/settings/notifications
More information about the DTrace-devel
mailing list