Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322594

Summary:	[launcher] initialArgv array not always null terminated
Product:	[Eclipse Project] Equinox	Reporter:	Andrew Niefer <aniefer>
Component:	Framework	Assignee:	equinox.framework-inbox <equinox.framework-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	tjwatson
Version:	3.6
Target Milestone:	3.7 M2
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Andrew Niefer

2010-08-12 18:01:44 EDT

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.

Comment 1 Andrew Niefer

2010-08-12 18:30:36 EDT

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

Comment 2 Thomas Watson

2010-08-13 09:06:28 EDT

Is this something that is causing crashes.  Is it something to consider for 3.6.1?  Do you have a fix?

Comment 3 Andrew Niefer

2010-08-13 14:42:48 EDT

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.

Comment 4 Andrew Niefer

2010-08-17 15:45:19 EDT

fixed in HEAD