[USDT] Lttng tracing improvements.

[GlenTiki]

Hey guys,

So, first off, I'm doing some work on the lttng tracepoints in core. I'm willing to take some suggestions of where to place some tracepoints to get valuable information out. :)

Also I'm seeing a problem with the placement with an existing tracepoint, and I'm wondering can I get some help/guidance on how to deal with it.

So, what we have is a bunch of LTTNG_TRACEPOINTS defined here: https://github.com/nodejs/node/blob/master/src/node_lttng.cc
The issue I'm working on is that when LTTNG_NET_SERVER_CONNECTION is called, there is a valid args._handle object defined, which gives us an fd for the incoming connection. Then, when that connection is ended, LTTNG_NET_STREAM_END is called. But the issue here is that when that is called, the args._handle has been set to null, so you can't connect to two connections based upon the fd the socket worked with.

I have done some digging, and this is what I found. LTTNG_NET_SERVER_CONNECTION is called here: https://github.com/nodejs/node/blob/master/lib/net.js#L1428
This is after the socket is instantiated and the socket._handle is set.
LTTNG_NET_STREAM_END is called here: https://github.com/nodejs/node/blob/master/lib/net.js#L403 but at this stage, I'm seeing the socket._handle is set to null so we lose the fd, and the tracepoint sets it to one. socket._handle has been set to null here: https://github.com/nodejs/node/blob/master/lib/net.js#L472

So, I guess that this was a choice of core as to how they destroy sockets, but that means the output of LTTNG_NET_STREAM_END is kinda meaningless, because the fd is set to -1 and I cant connect the server connection to the stream end. Should I create a different tracepoint for in socket._destroy to get the fd when the socket is destroyed? or (unlikely) should I look at working on that net code?

[Qard]

That seems like a bug, in my opinion. The socket.end(...) function, where those end hooks have been placed, is only called by socket.destroySoon(...), which is not the only path for a socket to "end".

[GlenTiki]

So, how should it be handled? I don't know how to proceed about it, tbh :)

[Qard]

I'm not too sure either.

@trevnorris @piscisaureus @bnoordhuis Thoughts?

[trevnorris]

Reason we manually set _handle = null is because internally we run the destructor on the TCPWrap class. This would make the ._handle reference an empty object and any attempts to access it would cause your program to crash.

Are you simply attempting to trace back the close event to the connection event?

[Qard]

Yeah, it seems like using the fd to identify linkage would work in most cases, but not here.

[GlenTiki]

yeah, I am.