[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/dev-queue
  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