Community
Participate
Working Groups
On windows, command line arguments may be transformed from multi-byte characters to unicode. In this process the new argv array that gets created is not null terminated. This array does not have room for the null at the end. The initialArgv is created as a copy of this non-null-terminated array, it is created with room for the null, but the last element remains uninitialized. There is code in parseArgs that enforces a null termination of the argv array, however the argv array here does not actually have room at the end, this null is written into memory we don't own. Normal behaviour on Windows seems to be entering at the Unicode entry point, so the conversion does not happen. However, a cygwin compiled executable (used for testing) enters at the multi-byte entry point. As well, older versions of windows (win 98) likely enter as multi-byte.
The binaries we ship for windows are compiled using -entry:wmainCRTStartup which tells the OS to call wmain, so the multi-byte to unicode conversion does not happen here. The cygwin makefile does not specify this entry point, which is why we get the conversion happening during testing with cygwin binaries. http://msdn.microsoft.com/en-us/library/f9t8842e.aspx
Is this something that is causing crashes. Is it something to consider for 3.6.1? Do you have a fix?
It causes crashes in conjunction with the patch from bug 149994, and probably also if the user types -vmargs on the command line. However, this only happens if we have to do the multi-byte to unicode conversion. The executable we ship specifies the unicode entry point so I don't think anyone hits it. To hit this you need to use the cygwin compiled version, which I use for debug purposes, or you would need to be loading our exe in some other program that was explicitly calling the main() function instead of the wmain(). I don't think this needs to go in 3.6.1.
fixed in HEAD
