[DTrace-devel] [oracle/dtrace-utils] a27582: test: Add ERROR clause to prevent hang from runtim...

Mon Jan 26 19:31:11 UTC 2026

  Branch: refs/heads/devel
  Home:   https://github.com/oracle/dtrace-utils
  Commit: a27582b56d414f3a234b4f4f0a64a9ef71b9b910
      https://github.com/oracle/dtrace-utils/commit/a27582b56d414f3a234b4f4f0a64a9ef71b9b910
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2026-01-26 (Mon, 26 Jan 2026)

  Changed paths:
    M test/unittest/funcs/strtok/tst.strtok.d
    M test/unittest/funcs/substr/tst.substr.d
    M test/unittest/types/tst.struct.d
    M test/unittest/types/tst.typedef.d

  Log Message:
  -----------
  test: Add ERROR clause to prevent hang from runtime error

These tests XFAIL.  Since they incur runtime failures, the scripts hang,
waiting for the test suite to time them out.

Add an ERROR clause to each test, so that XFAILs do not hang needlessly.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>

  Commit: 22573f69a04ef5aa93cfcf99560438d48f38f30a
      https://github.com/oracle/dtrace-utils/commit/22573f69a04ef5aa93cfcf99560438d48f38f30a
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2026-01-26 (Mon, 26 Jan 2026)

  Changed paths:
    M dtrace.spec

  Log Message:
  -----------
  spec: various fixes

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>

  Commit: 4d4197d727e25c4729e4b8db1984ead2a9bf5dd0
      https://github.com/oracle/dtrace-utils/commit/4d4197d727e25c4729e4b8db1984ead2a9bf5dd0
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2026-01-26 (Mon, 26 Jan 2026)

  Changed paths:
    M test/unittest/funcs/substr/tst.substr.d
    M test/unittest/funcs/substr/tst.substr.r
    M test/unittest/funcs/tst.basename.d
    M test/unittest/funcs/tst.basename.r
    M test/unittest/funcs/tst.index.d
    M test/unittest/funcs/tst.index.r

  Log Message:
  -----------
  test: expected results files should not be executable scripts

These tests generated a bash or perl script as output, but given that
the associated .r files are not meant to be executable, do not emit a
looks like a script but is not executable.

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>

  Commit: 1638eaff2941b72ab4556bd9debe4bb5dc640ad2
      https://github.com/oracle/dtrace-utils/commit/1638eaff2941b72ab4556bd9debe4bb5dc640ad2
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2026-01-26 (Mon, 26 Jan 2026)

  Changed paths:
    M libdtrace/dt_prov_fbt.c
    M libdtrace/dt_prov_rawtp.c
    A test/unittest/funcs/stack/tst.asgn_dvar.x
    A test/unittest/funcs/stack/tst.asgn_gvar.x
    A test/unittest/funcs/stack/tst.asgn_lvar.x
    A test/unittest/funcs/stack/tst.asgn_tvar.x
    A test/unittest/funcs/stack/tst.ref_addrs.x
    A test/unittest/printf/tst.stack.x
    A test/unittest/stack/tst.stack.x
    A test/utils/stack_skip_test.sh

  Log Message:
  -----------
  Change stack_skip to 3

For most probes, bpf_get_stack() strips off artificial BPF JIT stack
frames.  In a few cases -- like fprobes and rawtp -- we have to skip
the first few frames manually.  Typically, we should skip 3 frames
(trampoline, clause, and the bpf_get_stack call itself).  Further,
our BPF functions like
    get_bvar_caller()
    get_bvar_stackdepth()
    get_bvar_ucaller()
    get_bvar_ustackdepth()
skip an additional frame to account for that call.

Change stack_skip to 3 for the dt_fbt_fprobe and dt_rawtp providers.

This raises the thorny question of testing.  Until recently, the
stack_skip value we had been using -- 4, not 3 -- worked since it was
chosen empirically:  there was a bug in the kernel that added an extra
frame.  But now, the kernel situation is muddled.  The bug has been
fixed in recent kernels, but only for x86.  See

https://github.com/torvalds/linux/commit/6d08340d1e354787d6c65a8c3cdd4d41ffb8a5ed
Revert "perf/x86: Always store regs->ip in perf_callchain_kernel()"

A broader fix, for non-x86, is also expected.  See the thread that
starts at:
https://lore.kernel.org/all/a38fed68-67bc-98ce-8e12-743342121ae3@oracle.com/

So, for now, XFAIL tests on "unfixed" (older) kernels.

Orabug: 38776929
Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>

  Commit: b6c3d98bb6a11a9a6ab4a635f1104f1acf970d9e
      https://github.com/oracle/dtrace-utils/commit/b6c3d98bb6a11a9a6ab4a635f1104f1acf970d9e
  Author: Kris Van Hees <kris.van.hees at oracle.com>
  Date:   2026-01-26 (Mon, 26 Jan 2026)

  Changed paths:
    M libdtrace/dt_cc.c
    M libdtrace/dt_pid.c
    M libdtrace/dt_pid.h
    M libdtrace/dt_prov_uprobe.c

  Log Message:
  -----------
  pid, usdt, stapsdt: refactor dependency on pcb and dpr

The pid/usdt/stapsdt handling code in dt_pid.c was passing along both
dtp and pcb, while dtp->dt_pcb is known to provide the value of pcb
already.  This was done to handle a case where a fake pcb was being
passed (from dt_prov_uprobe.c) to ensure that dt_pid_error() would not
trigger a SEGV.

After careful code analysis, dt_pid_error() is restructured to handle
the case of pcb and/or dpr being NULL, so that the fake pcb is no
longer needed, and we can use dtp to get to the (possibly NULL) pcb.

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>

  Commit: 1cf5e40acd5c0c5fc63498411d7744d3fc5df63b
      https://github.com/oracle/dtrace-utils/commit/1cf5e40acd5c0c5fc63498411d7744d3fc5df63b
  Author: Eugene Loh <eugene.loh at oracle.com>
  Date:   2026-01-26 (Mon, 26 Jan 2026)

  Changed paths:
    M llm/llms-dtrace-complete.txt
    M llm/llms-dtrace-short.txt

  Log Message:
  -----------
  Update LLM context files to forbid "if" statements

Uploading the existing context file to generative AI using either
openai.gpt-4.1 or openai.gpt-5.2 led to the AI assistant producing D
scripts with "if" statements, even though such statements have never
been supported in the D language.  Asking the assistant why, it had
muddled explanations, like "if" being a reserved keyword in D, etc.

Modifying the context file to forbid "if" explicitly had limited success
at first.  In one case, the assistant explained, "The context clearly
states not to do that.  Despite this instruction, I used it likely due
to a habitual programming pattern."

I finally got a statement strong enough to eliminate the use of "if" for
some simple prompts I tried.  I used both openai.gpt-4.1 and 5.2, trying
each LLM with old and new context files, 3 times each since generate AI
is not deterministic.  The old file always result in "if";  the new file
never did.

There is currently no automated testing for these context files, which
clearly depend on the gen AI assistant anyhow.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
Reviewed-by: Elena Zannoni <elena.zannoni at oracle.com>

Compare: https://github.com/oracle/dtrace-utils/compare/91cdf5eb8a1e...1cf5e40acd5c

To unsubscribe from these emails, change your notification settings at https://github.com/oracle/dtrace-utils/settings/notifications