Double initialization of uv_tcp_t (probably any other uv_handle_t) cause random segfaults

[deniszykov]

Double initialization of uv_tcp_t (probably any other uv_handle_t) cause screw on handle->handle_queue and random segfaults in uv_*_init or uv_close.

I know this is obvious. But it took me a few days to find out in a large codebase that this was happening.
My suggestion is to make a flag that protects against re-initialization and to return an error code if this flag is set. In addition, this will save you from those who try to reuse handle's memory without zeroing it.

• Version: 1.42.1
• Platform: Windows

[vtjnash]

this cannot be done, since we make no assumption about the prior state of the memory

[deniszykov]

Ok, docs doesn't mention zeroing memory before init.
At least make a list of what lead to segfault somewhere in FAQ or docs. As far as I know:

• Allocating handles and requests on stack.
• Freeing handle memory before close callback.
• Freeing memory for in-flight requests.
• Calling any API not from loop thread, except uv_async_send.
• Double initializing handles.

[vtjnash]

I have proposed fixing this in v2 (#2630), but not yet sure it will get support

[deniszykov]

You got my thumbs-up :)
Looks safer, and if you need to pass additional info for allocator, this could be done with additional pointer parameter.

uv_tty_new(UV_STDIN_FD, arbitaryPointerForAllocator)

[bnoordhuis]

W.r.t. #3266 (comment) - I think most are mentioned throughout the docs already, just not in a centralized location.

I somewhat feel they're really just special cases of the general ownership issues you have to think about in C but I won't object to a "do's and don'ts" section in the intro if you want to send a pull request.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Matheus28]

For future reference:

Ok, docs doesn't mention zeroing memory before init.

You don't have to zero memory before init

Allocating handles and requests on stack.

This is okay, as long as you run the loop on the same stack or deeper until they're closed (used during tests, can't imagine very many uses of this in real code)

Freeing handle memory before close callback.
Freeing memory for in-flight requests.
Double initializing handles.

I feel like this is already expected with most C APIs

I think a lot of these come from a misunderstanding of how libuv (and most C libraries) treats memory you give it. For uv_*_init, it can't assume anything about it. So it can't check if they're already initialized, etc. Once you have called uv_*_init, you should expect to only be able to free that memory once the callback is called (for requests), or the close callback is called (for handles).

Calling any API not from loop thread, except uv_async_send.

I think there's a mention of this somewhere...

[RealYukiSan]

This is okay, as long as you run the loop on the same stack or deeper until they're closed (used during tests, can't imagine very many uses of this in real code)

So, what's the advantage using heap over stack in this case? I am not too familliar with memory-related subject, please explain to me if you don't mind @Matheus28