Debug assertion failure in in.read<std::string>() when deserializing empty string (Hazelcast C++ 5.2.5) [API-2284]

[pooja-achievement]

test_hazelcast_queue-cpp.txt### Summary

Deserializing an empty string using in.read<std::string>() in Hazelcast C++ client version 5.2.5 causes a debug assertion failure. The crash occurs internally within the Hazelcast client when the string being read was originally serialized as an empty value (""). This happens in debug builds on MSVC.

---

Environment

• Hazelcast C++ client version: 5.2.5
• Hazelcast Server version: Not relevant to the issue
• Operating system: Windows 10 / Windows 11
• Compiler: MSVC 2019 or MSVC 2022
• Build type: Debug

---

Steps to Reproduce

1. Define a struct with a char[] field (e.g., jobRequestUUID[51]).
2. Initialize the struct using memset, leaving the string field empty.
3. Push the struct into a Hazelcast queue using out.write(...).
4. Pop it using in.read<std::string>().
5. Observe that the debug build crashes during deserialization.

---

Expected Behavior

Empty strings should be safely deserialized by in.read<std::string>() without triggering a runtime assertion or crash.

---

Actual Behavior

Deserializing an empty string using in.read<std::string>() causes a debug assertion failure inside the Hazelcast C++ client. The issue appears to be related to STL string handling in debug builds when the string length is zero.

---

Minimal Reproduction

The issue can be reproduced using the attached file:
test_hazelcast_queue-cpp.txt

This file defines a minimal struct and queue wrapper, then performs a push and pop where the string field is left empty. The deserialization step crashes consistently in MSVC debug builds.

---

Workaround

Avoid writing empty strings directly by substituting a space " " as a placeholder, and clearing it on read:

// write
out.write(object.jobRequestUUID[0] ? object.jobRequestUUID : " ");

// read
std::string uuid = in.read<std::string>();
if (uuid == " ") uuid.clear();

---

Let me know if further details or trace output is needed.

[ihsandemir]

Hello @pooja-achievement Thanks for reporting this, and I appreciate the detail level you put in the issue. I will look at it and return to you shortly.

[pooja-achievement]

Hello @ihsandemir , thank you for the prompt response and for taking a look. I appreciate your time and will wait to hear back from you.

[github-actions]

Internal Jira issue: API-2284

[pooja-achievement]

Hi @ihsandemir, please let me know if there is any update on above issue. Thanks, Pooja!

[ihsandemir]

Hello @pooja-achievement There were multiple compiler problems with the code you shared. Please find attached is the corrected version

fixed_example.tar.gz

I ran the example and it works as expected:

11/06/2025 14:14:45.497 INFO: [0x16b887000] hz.client_1[dev] [5.3] (Tue Jun 10 16:44:22 2025 +0300:d9cf82d16) LifecycleService::LifecycleEvent Client (0e7ce0cb-ce66-46ae-acae-4f6e1c8b8c03) is STARTING
11/06/2025 14:14:45.498 INFO: [0x16b887000] hz.client_1[dev] [5.3] (Tue Jun 10 16:44:22 2025 +0300:d9cf82d16) LifecycleService::LifecycleEvent STARTING
11/06/2025 14:14:45.499 INFO: [0x16b887000] hz.client_1[dev] [5.3] LifecycleService::LifecycleEvent STARTED
11/06/2025 14:14:45.500 INFO: [0x16b887000] hz.client_1[dev] [5.3] Trying to connect to Address[127.0.0.1:5701].
11/06/2025 14:14:45.513 INFO: [0x16b887000] hz.client_1[dev] [5.3] LifecycleService::LifecycleEvent CLIENT_CONNECTED
11/06/2025 14:14:45.513 INFO: [0x16b887000] hz.client_1[dev] [5.3] Authenticated with server  Address[10.22.215.42:5701]:105e044e-486d-4ef3-ab9a-66de6e1fb8cf, server version: 5.5.5, local address: Address[127.0.0.1:63753]. Connection{alive=1, connection id=1, remote endpoint=Address[10.22.215.42:5701], last_read_time=2025-06-11 14:14:45.513, last_write_time=2025-06-11 14:14:45.501, closedTime=never, connected server version=5.5.5}
11/06/2025 14:14:45.515 INFO: [0x16cc37000] hz.client_1[dev] [5.3] 

Members [1]  {
	Member[10.22.215.42]:5701 - 105e044e-486d-4ef3-ab9a-66de6e1fb8cf
}

11/06/2025 14:14:45.516 WARNING: [0x16cf7f000] hz.client_1[dev] [5.3] No invocation for callId:  0. Dropping this message: ClientMessage{length=61, operation=, isRetryable=0, correlationId = 0, messageType = 0x304, flags = 0xc200, is backup aware = 0, is backup event = 0, isEvent = 1}, is_fragmented = no
[DEBUG] jobRequestUUID: ''
11/06/2025 14:14:45.521 INFO: [0x1ff584c80] hz.client_1[dev] [5.3] LifecycleService::LifecycleEvent SHUTTING_DOWN
11/06/2025 14:14:45.521 INFO: [0x1ff584c80] hz.client_1[dev] [5.3] Removed connection to endpoint: Address[10.22.215.42:5701], connection: Connection{alive=0, connection id=1, remote endpoint=Address[10.22.215.42:5701], last_read_time=2025-06-11 14:14:45.521, last_write_time=2025-06-11 14:14:45.520, closedTime=2025-06-11 14:14:45.521, connected server version=5.5.5}
11/06/2025 14:14:45.522 INFO: [0x1ff584c80] hz.client_1[dev] [5.3] LifecycleService::LifecycleEvent CLIENT_DISCONNECTED
11/06/2025 14:14:45.524 INFO: [0x1ff584c80] hz.client_1[dev] [5.3] LifecycleService::LifecycleEvent SHUTDOWN

Process finished with exit code 0

Can you please try with these fixes?

[pooja-achievement]

Hi @ihsandemir,

Thanks for the updated sample. I tried building the code from fixed_example.tar.gz using Hazelcast C++ client version 5.2.5. Initially, I ran into a boost::future related compilation error, which I resolved by adding the following defines at the top of the source file:

#define BOOST_THREAD_PROVIDES_FUTURE
#define BOOST_THREAD_PROVIDES_FUTURE_CONTINUATION
#define BOOST_THREAD_PROVIDES_EXECUTORS
#define BOOST_THREAD_USES_MOVE
#define BOOST_THREAD_PROVIDES_FUTURE_WHEN_ALL_WHEN_ANY
#define BOOST_ASIO_HAS_VARIABLE_TEMPLATES
#define BOOST_ASIO_HAS_PIPE

After adding these, the code compiled successfully in Visual Studio using Debug configuration.

However, at runtime, the application kept trying to create the Hazelcast client using this line:

auto hz = std::make_shared<hazelcast_client>(hazelcast::new_client().get());

but it was unable to obtain a client and kept retrying. So I changed this line to use our project’s wrapper:

auto hz = MyHazelcastWrapper::getInstance().getHazelCastClient();

This wrapper sets up the client using our existing configuration and has worked reliably in other cases.

With this change, the application runs but ends up with the same debug assertion failure at the exact place I encountered earlier. Since the same code seems to run fine on your end but crashes for me, I’m not sure if the issue is related to the extra defines I added, the way we retrieve the Hazelcast client through our wrapper, or something specific to Hazelcast 5.2.5.

I’ve attached all relevant screenshots including the assertion dialog, the code where it fails, and the call stack for your reference. Could you please confirm whether you're also testing with Hazelcast 5.2.5 and in Debug mode? Please let me know if you’d like me to upload more details for further analysis.

Thanks