Community
Participate
Working Groups
I call Spawner.exec_detached as follows: process.exec_detached(cmdArray, getEnvironmentStrings(), "."); This works in CDT 1.2.1, but fails in CDT 2.0. When executed, the application being launched fails with a C0150004 error (ERROR_SXS_ASSEMBLY_NOT_FOUND), which indicates that a specified assembly is not found. I traced the problem into Java_org_eclipse_cdt_utils_spawner_Spawner_exec1 in spawner.dll. For CDT 2.0, the file Win32ProcessEx.c was converted over to using Unicode functions, including calling CreateProcessW. However, when CreateProcessW is used, according to the MSDN documentation for the environment strings parameter: "An environment block can contain either Unicode or ANSI characters. If the environment block pointed to by lpEnvironment contains Unicode characters, be sure that dwCreationFlags includes CREATE_UNICODE_ENVIRONMENT." This change (the addition of CREATE_UNICODE_ENVIRONMENT to the launch flags) was made for exec0, but was not made to exec1, causing it to fail. Adding the following line just before the call to CreateProcessW fixes the problem: flags |= CREATE_UNICODE_ENVIRONMENT;
I think ... this was fix in the head and the branch(2_0_cdt). Alex could you take a second look, they maybe more to the story.
Thanks for reporting. That's correct. It was done for exec0 but missed for exec1 I've fixed it and it will be commited ASAP.
Was this fixed in 2.0.1? I just downloaded it, and -- inspecting the sources -- I don't see that it was fixed.
In revision 1.17 (commited 08/13/2004) lines 510-511: flags = CREATE_NEW_CONSOLE; flags |= CREATE_UNICODE_ENVIRONMENT;
> In revision 1.17 (commited 08/13/2004) lines 510-511: > flags = CREATE_NEW_CONSOLE; > flags |= CREATE_UNICODE_ENVIRONMENT; Alex, please flip your PR to "Fixed" status when you are done. Some testers in IBM can pick this one. They will not look at it if it is still open.
Fixed
OK, now that you've pointed it out, I see the change in CVS. I also see that revision 1.17 is tagged with CDT_2_0_1. However, I'm wondering if something went awry with the build: * If you download org.eclipse.cdt.sdk-2.0.1-win32.x86.zip and check out Win32ProcessEx.c, you will not see that change in the file. * If you use the Eclipse Update Manager to install CDT 2.0.1, you will get a version of spawner.dll that includes the following code: 10001ef8: 51 push %ecx 10001ef9: 52 push %edx 10001efa: 57 push %edi 10001efb: 50 push %eax 10001efc: 6a 10 push $0x10 10001efe: 6a 01 push $0x1 10001f00: 6a 00 push $0x0 10001f02: 8d 8c 24 a0 00 00 00 lea 0xa0(%esp),%ecx 10001f09: 6a 00 push $0x0 10001f0b: 51 push %ecx 10001f0c: 6a 00 push $0x0 10001f0e: ff 15 38 90 00 10 call *0x10009038 As you can see at location 10001efc, 0x10 is being pushed onto the stack, indicating that only CREATE_NEW_CONSOLE is being set, not CREATE_UNICODE_ENVIRONMENT.
This seems to be a configuration problem. Just wrong binary was included into 2.0.1 release. For now I just can recommend you check out correct binary from CVS. They will decide how to solve the problem later. Sorry for inconvinience.
Fixed in HEAD branch. Tagged as 2_0_1.
Keith, could you try again. We just update the spawner.dll in the branch the version should now 1.16.2.2 Thanks.
I can verify that version 1.6.2.2 of the dll contains the fix for the original problem. It functionally works for me, and disassembling the code shows that the right flag is set. However, the latest problem appears to be one of configuration, not of getting the code right. That is, the problem is related to getting the right dll into the build, not getting the dll right. I don't think I have any way of verifying the configuration or build process, other than taking an actual build from <http://update.eclipse.org/tools/cdt/releases/new> and trying it out.
reopening configuration problem
> I can verify that version 1.6.2.2 of the dll contains the fix for the original > problem. It functionally works for me, and disassembling the code shows that > the right flag is set. Excellent!! > However, the latest problem appears to be one of configuration, not of getting > the code right. That is, the problem is related to getting the right dll into > the build, not getting the dll right. I don't think I have any way of > verifying the configuration or build process, other than taking an actual > build from <http://update.eclipse.org/tools/cdt/releases/new> and trying it > out. Understood, reopening the bug and redirecting the our releng in chief Doug 8-) and Cc: ing to Dave Daoust.
Doug, Can you verify that this will make it into the next 2.0.X build? Maybe we should do a 2.0.2 build RC.
I have now way of knowing if the right dll got into the build. Both builds were off of the cdt_2_0 stream. diff says that the version in 2.0.1 is different than the new 2.0.2 build but they are the same size. The only way to tell is to try your scenario out the new build from the 2.0.2 build page. http://download.eclipse.org/tools/cdt/builds/2.0.2.
> I have now way of knowing if the right dll got into the build. Both builds were > off of the cdt_2_0 stream. diff says that the version in 2.0.1 is different > than the new 2.0.2 build but they are the same size. I think, the new dll was commited in the head but not move to the branch(2_0). After that we did not worry since tag was showing the right version. So the correct one is now commited to the branch(verified by keith): >> I can verify that version 1.6.2.2 of the dll contains the fix for >> the original problem. It functionally works for me, and >> disassembling the code shows that the right flag is set. All is well in the land. You can mark this as verified. 2.0.2 will have the correct DLL.
