Repository navigation
HRX: libhip_logging writes no output despite HIP_LOG_FILE/HIP_LOG_LEVEL #411
Description
HRX: libhip_logging never writes its log file
The logging interceptor in HRX's passthrough set (libhip_logging.so) loads and forwards HIP
calls correctly, but produces no output — no log file and nothing on stderr — even when its
documented environment variables are set.
Repro
export HIP_PASSTHROUGH_BACKEND_LIB=<path>/libamdhip64.so.7
export HIP_PASSTHROUGH_INTERCEPTOR=<path>/libhip_logging.so
export HIP_LOG_FILE=/tmp/hip.log
export HIP_LOG_LEVEL=2 # 2 = log calls (documented default)
LD_LIBRARY_PATH=<passthrough>:<backend> ./any_hip_programObserved:
| Check | Result |
|---|---|
| program runs correctly | yes — forwarding is transparent |
/tmp/hip.log created |
no (file does not exist) |
anything on stderr with HIP_LOG_LEVEL=2 |
nothing |
same run omitting HIP_LOG_FILE (documented default = stderr) |
nothing |
What is known
- The interceptor's ABI is present and correct: the library exports
hip_interceptor_init,hip_interceptor_shutdown, andhip_interceptor_get_log_fn. - The variables are read:
HIP_LOG_FILEatlibhrx/src/passthrough/hip_logging.c:569and
HIP_LOG_LEVELat:580. - The proxy loads it correctly with
dlopen(..., RTLD_NOW | RTLD_LOCAL)and calls
hip_interceptor_initwith the real function table
(libhrx/src/passthrough/hip_intercept.c:143,146). - Loading the interceptor does not break anything — calls still reach the backend.
So init appears to succeed but logging is never emitted. Possible causes worth checking first:
the interceptor table returned by hip_interceptor_init may not be replacing the real table
(silent fallthrough to the unwrapped path), or the log sink is initialised lazily and never
reached.
Impact
Low — this is a diagnostic tool, not a runtime path. But libhip_logging is the documented way
to trace HIP calls, and it currently gives the user no signal at all that it is (or is not)
working: a silent no-output run looks identical to "the program made no HIP calls".
Failing loudly (or writing a header line on init) would be enough to make it diagnosable.
Note
:569/:580 are the observed line numbers; treat them as approximate if the file has moved.
Activity
bong-water-water-bong commentedon Oct 13, 2026
Correction — this is NOT a defect, and the report is withdrawn
I filed this after running the interceptor incorrectly. My test never loaded the proxy, so
the interceptor was never invoked and no output was ever going to appear.
Two mistakes on my side:
The proxy was not preloaded. I placed
libhip_intercept.soonLD_LIBRARY_PATH, but thetest program is linked against
libamdhip64.so.7, so the dynamic linker satisfied its HIPsymbols directly from the real library. The interceptor was never in the call path at all
(
lddconfirmed:libamdhip64.so.7 => …/libamdhip64.so.7).Wrong variable name.
hip_intercept.creads the interceptor path fromHIP_INTERCEPTION_LIBRARY, while the README documentsHIP_PASSTHROUGH_INTERCEPTOR.Following the README selects nothing.
It works when invoked correctly
produces:
Every HIP call is logged with a timestamp and return code.
libhip_buffer_tracerlikewise works(it reported
Total kernels traced: 0,Total buffers tracked: 0, and logged eachhipMalloc/hipMemsetwith pointers).The one real finding that survives
The documented environment variable does not match the code.
hip_intercept.creadsHIP_INTERCEPTION_LIBRARY; the passthrough README documentsHIP_PASSTHROUGH_INTERCEPTOR. Auser following the README gets a silently un-instrumented run with no warning — which is exactly
what happened to me and is why I misdiagnosed this as a library defect.
Suggestion: read both names (the documented one taking precedence), or correct the README.
Closing as not a bug. Apologies for the noise — the failure was in my test harness, not in
HRX.