[DTrace-devel] [PATCH] Add support for inet_ntop() subroutine

Kris Van Hees kris.van.hees at oracle.com
Thu Sep 14 03:12:52 UTC 2023


On Wed, Sep 13, 2023 at 07:44:57PM -0400, Eugene Loh via DTrace-devel wrote:
> (common problem of not seeing the patch in my inbox)
> 
> Reviewed-by: Eugene Loh <eugene.loh at oracle.com>
> 
> However, one problem is that there are bad tstring leaks... the tstrings are
> simply not being reclaimed.  Maybe in the ternary construction, there should
> be a
>         +    dt_node_type_assign(tnp, DT_STR_CTFP(dtp), DT_STR_TYPE(dtp));
> or so.  By identifying tnp as a string, I think that triggers the tstring
> cleanup stuff in dt_cg_ternary_op().

On what basis are you saying that there is a tstring leak?  Adding debugging to
the code I see all tstrings getting free'd as they ought to be.  The result
tstring is movevd to the dnp node, and it is free'd from there when the dnp is
consumed by the trace() action.

> Also, there is the issue of different formats for IPv4 addresses embedded
> IPv6.  The resulting format is different depending on whether one uses
> inet_ntoa6(addr) or inet_ntop(AF_INET6, addr).  I think there were some easy
> fixes to this with the first proposal for inet_ntop(), but I struck out how
> to do this with the current ntop patch.  So, maybe we just use the same
> format for both ntoa6 and ntop?  If so, then the IPv4 results in
> test/unittest/funcs/tst.inet_ntop.r should have their :: and ::ffff:
> prefixes stripped.

Yes, we discussed that.  I'll have a look and see if I can do something about
it.

	Kris



More information about the DTrace-devel mailing list