Problem with dtrace and function parameters

Concerning PR 269770, I am trying to watch what is going in and
out of my libalias. So I am looking at this function in alias_db.c:

> struct alias_link *
> AddLink(struct libalias *la, struct in_addr src_addr, struct in_addr dst_addr,
>     struct in_addr alias_addr, u_short src_port, u_short dst_port,
>     int alias_port_param, int link_type)
> {

I cannot read args[1], because when I'm doing
>   printf("%d", args[1].s_addr)
that is understood, but then:
>   dtrace: error on enabled probe ID 1 (ID 49947:
>   fbt:kernel:AddLink:entry): invalid address (0x<my ip address>)
>   in action #4 at DIF offset 8

Actually my IP address is not invalid, but dtrace seems to have
difficulties understanding the difference between an IP address
and a memory address. ;)

So I started to do it in the brute way (linefeeds inserted for readability):

# dtrace -n 'AddLink:entry { printf("%s %d %d
            (src_port %d) (dst_port %d) (alias_p %d) (link_type %d)
	    (src_addr %d.%d.%d.%d %d.%d.%d.%d)
	    (dst_addr %d.%d.%d.%d %d.%d.%d.%d)
	    (alias_addr %d.%d.%d.%d %d.%d.%d.%d)
	    (src_port %d.%d.%d.%d %d.%d.%d.%d)
	    (dst_port %d.%d.%d.%d %d.%d.%d.%d)
	    (alias_port_param %d.%d.%d.%d %d.%d.%d.%d)
	    (link_type %d.%d.%d.%d %d.%d.%d.%d)
	    (unused %d.%d.%d.%d %d.%d.%d.%d)
	    (unused %d.%d.%d.%d %d.%d.%d.%d)",
	    execname, walltimestamp/1000000000, args[0]->udpLinkCount,
	    args[4],args[5], args[6], args[7],
	    arg1/4294967296%256, arg1/4294967296/256%256,
	      arg1/4294967296/65536%256, arg1/4294967296/16777216,
	      arg1%256, arg1/256%256, arg1/65536%256, arg1/16777216,
	    arg2/4294967296%256, arg2/4294967296/256%256,
	      arg2/4294967296/65536%256, arg2/4294967296/16777216,
	      arg2%256, arg2/256%256, arg2/65536%256, arg2/16777216,
	    arg3/4294967296%256, arg3/4294967296/256%256,
	      arg3/4294967296/65536%256, arg3/4294967296/16777216,
	      arg3%256, arg3/256%256, arg3/65536%256, arg3/16777216,
            arg4/4294967296%256, arg4/4294967296/256%256,
	      arg4/4294967296/65536%256, arg4/4294967296/16777216,
	      arg4%256, arg4/256%256, arg4/65536%256, arg4/16777216,
	    arg5/4294967296%256, arg5/4294967296/256%256,
	      arg5/4294967296/65536%256, arg5/4294967296/16777216,
	      arg5%256, arg5/256%256, arg5/65536%256, arg5/16777216,
	    arg6/4294967296%256, arg6/4294967296/256%256,
	      arg6/4294967296/65536%256, arg6/4294967296/16777216,
	      arg6%256, arg6/256%256, arg6/65536%256, arg6/16777216,
	    arg7/4294967296%256, arg7/4294967296/256%256,
	      arg7/4294967296/65536%256, arg7/4294967296/16777216,
	      arg7%256, arg7/256%256, arg7/65536%256, arg7/16777216,
	    arg8/4294967296%256, arg8/4294967296/256%256,
	      arg8/4294967296/65536%256, arg8/4294967296/16777216,
	      arg8%256, arg8/256%256, arg8/65536%256, arg8/16777216,
	    arg9/4294967296%256, arg9/4294967296/256%256,
	      arg9/4294967296/65536%256, arg9/4294967296/16777216,
	      arg9%256, arg9/256%256, arg9/65536%256, arg9/16777216); }

Now the output looks like this, and while the IP addresses are fine,
the remainder is obviousely bogus, and seems neither to resolve
via network byte order nor via 64-32 bit conversions to anything
useful - and no, these numbers do not make more sense when casting
all to unsigned, they only look better.

AddLink:entry openvpn 1708539730 2
     (src_port 20931) (dst_port 46672) (alias_p 70) (link_type -2045910784)
     (src_addr 0.0.0.0 <my ip address>)
     (dst_addr 0.0.0.0 46.17.96.38)
     (alias_addr 0.0.0.0 <my ip address>)
     (src_port 0.0.0.0 195.81.0.0)
     (dst_port -254.-1.0.0 -176.-73.-201.-130577)
     (alias_port_param 0.0.0.0 70.0.0.0)
     (link_type -253.-7.0.0 0.-31.-242.-523641)
     (unused 0.0.0.0 <my ip address>)
     (unused 0.0.0.0 46.17.96.38)

BTW, this is the packet concerned:
ipfw-oper: 2422 Count TCP 46.17.96.38:55812 <my ip address>:50001 in via tun3

The last parameter that makes sense here is the src_port, apparently in
network order. Everything afterwards seems to be just crap.

Any ideas why, anybody?