LTTng » LTTng-tools

So it appears that the socket operation functions pointer is invalid (NULL or bad address) in this case which causes the segfault.

I found one code path that could trigger that but it does not fit the one I see in the coredump being a relayd_close() in a call_rcu... If a relayd socket is in the relayd hash table, it means that the sockets were all successfully allocated and initialized. Seeing invalid stuff in the operation pointer is kind of "not possible" because to trigger a call rcu, a relayd object has to be in the hash table meaning initialized correctly.

Anyway, I'll push a fix to make sure we have a valid op. functions pointer for the socket when calling relayd_close() because I see at least when code path that needs that. Hopefully, it won't trigger again the problem you've been having avoiding to dereference the operations.

Btw, again, if you can provide coredumps with no optimization, that would help a lot because we can never be sure of the root cause with stuff optimized out.

Thanks!

I've attached a patch to the bug to improve relayd_close() and should fix having an invalid ops pointer.

This needs review because it adds a default fallback on close(3) if no ops is found which can be debated. Also, if the fd is not valid, it will still return a success.

Yep, I'll push that in 2.1-stable and port the fix to 2.2 if necessary.

Thanks!

Applied in changeset 6d4c7a40b1050245ed51c198189d47b4b3183c43.