Init order for the dynamic_init_dummy in the generated code and fixed_address_empty_string is unpredictable

[jinghli]

What version of protobuf and what language are you using?
Version: 3.17.3
Language: C++

What operating system (Linux, Windows, ...) and version?
Windows
What runtime / compiler are you using (e.g., python version or gcc version)
MSVC140
What did you do?
Link protobuf lib to my application. I saw 8 byte memory leak in runtime coming from protobuf.

We had a very simple proto file in the production code, the structure looks like this

syntax="proto2";

message test
{
    optional uint32 Version = 1 [default = 1];
	optional uint64 id = 2;
}

There is a global static var in the generated code

// Force running AddDescriptors() at dynamic initialization time.
PROTOBUF_ATTRIBUTE_INIT_PRIORITY static ::PROTOBUF_NAMESPACE_ID::internal::AddDescriptorsRunner dynamic_init_dummy_test_2eproto(&descriptor_table_test_2eproto);

During the initialization, I can see dynamic_init_dummy_test_2eproto initialization actually zero-out fixed_address_empty_string in generated_message_util.cc(line 70). It eventually causes the shutdown process won't clean up memory completely. We think it is caused by the unpredictable init order for those two variables.

What did you expect to see
Expect no memory leak
What did you see instead?
Leak 8 bytes
Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).

Anything else we should know about your project / environment

[elharo]

Thanks. We probably need a full reproducible test case to investigate this.

[jinghli]

Thanks for following up. Totally understand. I'd need a bit time to craft the code to re-pro this issue without our business logic.

[snnn]

It looks very similar to #8129.

[deannagarcia]

Closing because of no reproduction case, feel free to open it back up if you have one!