wrong value from DTRACE (uint32 for int64)

Peter peter at citylink.dinoex.sub.org
Mon Dec 2 20:13:29 UTC 2019


Hi @all,

I felt the need to look into my ZFS ARC, but DTRACE provided misleading  
(i.e., wrong) output (on i386, 11.3-RELEASE):

# dtrace -Sn 'arc-available_memory { printf("%x %x", arg0, arg1); }'
DIFO 0x286450a0 returns D type (integer) (size 8)
OFF OPCODE      INSTRUCTION
00: 29010601    ldgs DT_VAR(262), %r1           ! DT_VAR(262) = "arg0"
01: 23000001    ret  %r1

NAME             ID   KND SCP FLAG TYPE
arg0             262  scl glb r    D type (integer) (size 8)

DIFO 0x286450f0 returns D type (integer) (size 8)
OFF OPCODE      INSTRUCTION
00: 29010701    ldgs DT_VAR(263), %r1           ! DT_VAR(263) = "arg1"
01: 23000001    ret  %r1

NAME             ID   KND SCP FLAG TYPE
arg1             263  scl glb r    D type (integer) (size 8)
dtrace: description 'arc-available_memory ' matched 1 probe
   0     14        none:arc-available_memory 2fb000 2
   0     14        none:arc-available_memory 4e000 2
   1     14        none:arc-available_memory ffffb000 2
   1     14        none:arc-available_memory ffffb000 2
   1     14        none:arc-available_memory ffffb000 2
   1     14        none:arc-available_memory 19000 2
   0     14        none:arc-available_memory d38000 2

# dtrace -n 'arc-available_memory { printf("%d %d", arg0, arg1); }'
   1     14        none:arc-available_memory 81920 5
   1     14        none:arc-available_memory 69632 5
   1     14        none:arc-available_memory 4294955008 5
   1     14        none:arc-available_memory 4294955008 5


The arg0 Variable is shown here obviousely as an unsigned int32 value. But  
in fact, the probe in the sourcecode in arc.c is a signed int64:

         DTRACE_PROBE2(arc__available_memory, int64_t, lowest, int, r);


User @shkhin in the forum pointed me to check the bare dtrace program,  
unattached to the kernel code:
https://forums.freebsd.org/threads/dtrace-treats-int64_t-as-uint32_t-on-i386.73223/post-446517

And there everything appears correct.

So two questions:
1. can anybody check and confirm this happening?
2. any idea what could be wrong here? (The respective variable in arc.c  
bears the correct 64bit negative value, I checked that - and otherwise the  
ARC couldn't shrink.)

rgds,
PMc


More information about the freebsd-stable mailing list