Possible Photon library JString conversion bug
Options
Hi, I have run into an issue which may or may not have been addressed in later versions, but I will post here to inform anyway.
To summarize, there might be an issue with JString conversions between unicode/ascii representations. JString implicit casting calls are returning an arbitrary number of additional invalid characters on certain special characters.
Description:
- Our photon cpp client (version 3.0.0.0) is receiving a string value from our server (version 3.2.10.4248) via this call:
ExitGames::JString* msg = ((ExitGames::ValueObject<ExitGames::JString>*)messages->getValue(ExitGames::KeyObject<int>(3)))->getDataAddress();
- These two calls were made to access the string.
std::string sMsg(msg->UTF8Representation().cstr());
...
std::wstring message=*msg;
- However, random string lengths were output upon testing multiple times, even though the server was sending the same string.
An example:
- A user sent the owlface ascii character to the server.
Dem metal chickens ಠ_ಠ
- This is represented in unicode and broadcast to all users.
- Users reported random crashing of the application, and we investigated.
- The server stores this as unicode as 'Dem metal chickens ಠ_ಠ' which is 26 characters including the non printable characters.
- This is the character output of the JString functions for multiple calls with the same input:
(character index: ascii number of character)
0:68 1:101 2:109 3:32 4:109 5:101 6:116 7:97 8:108 9:32 10:99 11:104 12:105 13:99 14:107 15:101 16:110 17:115 18:32 19:224 20:178 21:160 22:95 23:224 24:178 25:160
0:68 1:101 2:109 3:32 4:109 5:101 6:116 7:97 8:108 9:32 10:99 11:104 12:105 13:99 14:107 15:101 16:110 17:115 18:32 19:224 20:178 21:160 22:95 23:224 24:178 25:160 26:68 27:1703936 28:2 29:1639419350 30:68 31:22 32:460904672 33:105
0:68 1:101 2:109 3:32 4:109 5:101 6:116 7:97 8:108 9:32 10:99 11:104 12:105 13:99 14:107 15:101 16:110 17:115 18:32 19:224 20:178 21:160 22:95 23:224 24:178 25:160 26:11 27:458752 28:16 29:16
- This means that on random calls to the JString functions for conversion, it may or may not give us the desired output of 26 characters. Sometimes, the conversion appends additional characters after the 26th character, which will cause the functions to return an undefined variable, which in turn crashes our application.
- As a quick fix, we are sending the number of characters from the server to the client in order to truncate the JString to remove any additional characters.
To summarize, there might be an issue with JString conversions between unicode/ascii representations. JString implicit casting calls are returning an arbitrary number of additional invalid characters on certain special characters.
Description:
- Our photon cpp client (version 3.0.0.0) is receiving a string value from our server (version 3.2.10.4248) via this call:
ExitGames::JString* msg = ((ExitGames::ValueObject<ExitGames::JString>*)messages->getValue(ExitGames::KeyObject<int>(3)))->getDataAddress();
- These two calls were made to access the string.
std::string sMsg(msg->UTF8Representation().cstr());
...
std::wstring message=*msg;
- However, random string lengths were output upon testing multiple times, even though the server was sending the same string.
An example:
- A user sent the owlface ascii character to the server.
Dem metal chickens ಠ_ಠ
- This is represented in unicode and broadcast to all users.
- Users reported random crashing of the application, and we investigated.
- The server stores this as unicode as 'Dem metal chickens ಠ_ಠ' which is 26 characters including the non printable characters.
- This is the character output of the JString functions for multiple calls with the same input:
(character index: ascii number of character)
0:68 1:101 2:109 3:32 4:109 5:101 6:116 7:97 8:108 9:32 10:99 11:104 12:105 13:99 14:107 15:101 16:110 17:115 18:32 19:224 20:178 21:160 22:95 23:224 24:178 25:160
0:68 1:101 2:109 3:32 4:109 5:101 6:116 7:97 8:108 9:32 10:99 11:104 12:105 13:99 14:107 15:101 16:110 17:115 18:32 19:224 20:178 21:160 22:95 23:224 24:178 25:160 26:68 27:1703936 28:2 29:1639419350 30:68 31:22 32:460904672 33:105
0:68 1:101 2:109 3:32 4:109 5:101 6:116 7:97 8:108 9:32 10:99 11:104 12:105 13:99 14:107 15:101 16:110 17:115 18:32 19:224 20:178 21:160 22:95 23:224 24:178 25:160 26:11 27:458752 28:16 29:16
- This means that on random calls to the JString functions for conversion, it may or may not give us the desired output of 26 characters. Sometimes, the conversion appends additional characters after the 26th character, which will cause the functions to return an undefined variable, which in turn crashes our application.
- As a quick fix, we are sending the number of characters from the server to the client in order to truncate the JString to remove any additional characters.
0
Comments
-
Hi mookanana.
This comes from a known bug in the Client SDK that has been fixed with the 3.0.3.0 release, so please update to a more recent version.
If you can't update to the most recent version, I would recommend you to at least update to 3.0.3.11 (downloadable at https://dl.dropboxusercontent.com/u/429 ... 11_SDK.zip) so that you profit from as many bugfixes as possible without the need of adjusting your codebase to major changes.0
