-
Notifications
You must be signed in to change notification settings - Fork 380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix error in ACE_Process_Options::inherit_environment () #2006
base: master
Are you sure you want to change the base?
Fix error in ACE_Process_Options::inherit_environment () #2006
Conversation
…ingly ::WideCharToMultiByte) there must be expected that the length of the ouput multi-byte string is not equal to the length of the input unicode string. That's why we the variable iter used to iterate over the original unicode environment varaiables must be increased by the source string length (and not by the length of converted string).
Please extend one of the unit tests under ACE/tests in such a way that it reproduces the issue you found |
The error was found in conjunction with Implementation Repository Activator. On one Chinese Windows machine the Activator could not start a managed server.
The error occurs on the step 2. The variables occupy a continuous book of memory and are separated by '\0' char in that block. Mistakenly inherit_environment() assumes that the length of the output string of ::WideCharToMultiByte equals to the length of the input string in characters, what is only try for ASCII strings. But if the input string contains characters which cannot be presented with 1 byte (like Chinese) these characters will be presented with 2 bytes in the output string and the length of this string in chars will be longer. Consider variables: They are passed to ::CreateProcess as: (Note that The name PATHEXT is cut from the result list.) ACE was built with ACE_HAS_WCHAR only. (ACE_USES_WCHAR was not defined) |
Please extend one of the unit tests as reproducer |
@coderabbitai full review |
✅ Actions performedFull review triggered. |
WalkthroughThe changes update the iterator advancement in the Changes
Sequence Diagram(s)sequenceDiagram
participant Caller
participant Process as ACE_Process_Options
participant OS as ACE_OS
Caller->>Process: Call inherit_environment()
loop Process Environment Array
Process->>OS: Call ACE_OS::strlen(iter)
OS-->>Process: Return string length
Process->>Process: Increment iterator by returned length
end
Poem
Tip 🌐 Web search-backed reviews and chat
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
ACE/ace/Process.cpp (1)
924-939
: Add error handling and improve documentation.The code could benefit from:
- Error handling for memory allocation failures
- Documentation explaining the multi-byte character handling
- Bounds checking for string operations
Consider applying these improvements:
ACE_Vector<char> temp_narrow_env; +// Convert wide environment strings to narrow, handling multi-byte characters +// Note: Each wide character may convert to multiple bytes if (this->use_unicode_environment_) { existing_wide_env = ::GetEnvironmentStringsW (); + if (!existing_wide_env) + { + ACELIB_ERROR ((LM_ERROR, + ACE_TEXT ("Failed to get environment strings"))); + return; + } for (WCHAR *iter = existing_wide_env; *iter; ++iter) { ACE_Wide_To_Ascii wta (iter); + if (!wta.char_rep()) + { + ACELIB_ERROR ((LM_ERROR, + ACE_TEXT ("Failed to convert environment string"))); + ::FreeEnvironmentStringsW (existing_wide_env); + return; + } size_t const len = ACE_OS::strlen (wta.char_rep ()); size_t const idx = temp_narrow_env.size (); + try { temp_narrow_env.resize (idx + len + 1, 0); + } catch (const std::bad_alloc&) { + ACELIB_ERROR ((LM_ERROR, + ACE_TEXT ("Failed to allocate memory for environment"))); + ::FreeEnvironmentStringsW (existing_wide_env); + return; + } ACE_OS::strncpy (&temp_narrow_env[idx], wta.char_rep (), len); iter += ACE_OS::strlen(iter); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
ACE/ace/Process.cpp
(1 hunks)
🔇 Additional comments (2)
ACE/ace/Process.cpp (2)
935-935
: Correct fix for environment variable handling with multi-byte characters.The change correctly advances the iterator using the source string length instead of the converted string length. This is essential for proper handling of multi-byte characters (e.g., Chinese) where the converted string length can be different from the source string length.
Please add a test case to verify this fix. The test should:
- Set up environment variables containing multi-byte characters
- Call
inherit_environment()
- Verify that all environment variables are correctly inherited
Would you like me to help create a test case that reproduces the issue and verifies the fix?
913-969
: Extend test coverage for environment inheritance.As requested by jwillemsen, please extend the unit tests to cover:
- Environment inheritance with multi-byte characters
- Error conditions (memory allocation, conversion failures)
- Mixed ASCII and multi-byte environment variables
Let's verify the existing test coverage:
Would you like me to help create comprehensive test cases that cover these scenarios?
While using ACE_Wide_To_Ascii string conversion class (and correspondingly ::WideCharToMultiByte) there must be expected that the length of the output multi-byte string is not equal to the length of the input Unicode string. That's why the variable iter used to iterate over the original Unicode environment variables must be increased by the source string length (and not by the length of the converted string).
Summary by CodeRabbit