Setting TLS config option via nng_socket_set_ptr causes access violation if you free config

[DoumanAsh]

Describe the bug
Subj

Expected behavior
Perform increment of refcount within setter function?

Actual Behavior
User is required to make shallow copy of tls config

To Reproduce
If possible include actual reproduction test code here.
Minimal C test cases are perferred.

Environment Details

• NNG version - 1.8.0
• Operating system and version - Windows 10
• Compiler and language used - C (to compile nng)/Rust(bindings)
• Shared or static library - static

Additional context

Dialer/Listener setters would increment refcount, but it seems that's not the case when using socket option as it causes use after free according to Dr.Memory
But I suspect TLS is not properly supported to be set via nng_socket_set_ptr anyway.
Still I thought to report it as this behavior is not very well documented

[gdamore]

Thank you for the bug report. I will investigate... there is going to be more work in this general area anyway -- but definitely its the case that the TLS configuration struct does not "borrow" a reference counter.

[DoumanAsh]

Oh I see, so setting TLS config on socket itself is supported?
Because I remember seeing no special handling for it in setter https://github.com/nanomsg/nng/blob/master/src/core/socket.c#L1048

If it is supported that is definitely needs to be fixed to increment refcount 😄

[gdamore]

The caller has to keep the configuration around for now. Which is unfortunate. The problem is that with some of these configuration objects we don't have a good way to clone them, because they are linked to the configuration of the underlying TLS library which might have e.g. linked lists, etc.

I'm going to refactor this to have "native" NNG configuration data instead I think.