Description Raphael Zulliger 2011-01-05 11:03:23 EST

Build Identifier: 20100617-1415

Facts:
 - After having compiled starter.exe with the DEBUG_MONITOR compiler directive, it reports the mentioned DebugOutput messages when starting a process (e.g. during the start of a debugging session using gdb.exe).
 - This happens on my Windows 7 (64bit) system
 - This does not happen on my Windows XP (32bit) system
 - DisplayErrorMessage() reports "Access denied" (which roots from ERROR_ACCESS_DENIED)
 - According to MSDN, this error is returned if the process has already been assigned to a job object (see http://msdn.microsoft.com/en-us/library/ms681949%28v=vs.85%29.aspx)

Here's the (shortened) DebugView output (note "Zugriff verweigert" is German for "Access denied"):

[5004] Starting: gcc -E -P -v -dD C:/Users/zulli/runtime-EclipseApplication/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c 
[5004] Process 3136 started
[5004] Cannot assign process 3136 to a job
[5004] Zugriff verweigert 
[5004] starter: launched process has been terminated(PID 3136)


Conclusions:
First of all, note that till yesterday I haven't ever heard about those "job objects" (so I'm a rookie). Anyway, my conclusions are as following:
 - Windows 7 (just a guess: probably also Vista due to UAC) behaves differently than Windows XP: According to the ProcessExplorer, the eclipse.exe process (on Windows 7) is already part of a job object. Therefore, starter.exe, as well as gdb.exe will automatically inherit this property and become part of the same job object. Thus, when starter.exe tries to assign the gdb.exe process to a new job. we receive the "Access denied" failure. On Windows XP, eclipse.exe seems to be not part of any job object by default (according to the ProcessExplorer). I therefore assume, that this "default behavior" changed with new Windows releases.
 - According to my investigations, it would help to call CreateProcess(..., "gdb.exe", ...) with the CREATE_BREAKAWAY_FROM_JOB flag. This would create the gdb.exe process independent from any job object. I patched starter.exe like this and tested the patched version on my two Windows systems. According to my tests, the path didn't have any effect on Windows XP (which is a good thing, IMHO) but it caused the initially mentioned error to disappear on Windows 7 (which is, again, good). Also, according to ProcessExplorer, the gdb.exe process will indeed be part of a separate/new job object on Windows XP & 7 with the mentioned patch applied.
=> In short: As far as I can tell, the mentioned patch should be applied.

Question: What happens, if we don't fix this issue? 
Answer: I don't know...
Let's do some guessing: According to starter.cpp, the "job object" will be terminated if Eclipse/CDT asks to kill the started process (which is gdb.exe in the mentioned example). I don't know what happens if a process terminates a job object (by calling TerminateJobObject) of which the process is itself part of... The worst case I could imagine is that such a call would terminate not only the gdb.exe process, but also the whole eclipse.exe process.
If someone can point me to a use case for which Eclipse/CDT issues a "kill" to starter.exe, I would test it. I was not able to produce such a situation "out of the box".

Btw: Bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=213994 is not directly related to this issue. I didn't test the patch proposed by that bug report, but I assume that it won't clash with the patch proposed here.

Reproducible: Always

Steps to Reproduce:
1. Use Windows 7 (64bit). Note: I'm pretty sure it'll be reproducible by Windows 7 32bit as well. Moreover, my guess is that it'll even be reproducible with Windows Vista (32/64Bit) - but that's just a guess
2. Start Eclipse
3. Create a CDT/C++ project (with whatever content)
4. Start a debugging session (which creates a gdb.exe process)
5. Start the "Process Explorer" from Sysinternals (http://technet.microsoft.com/en-us/sysinternals/bb896653)
6. Check the properties of the gdb.exe process: You'll notice that it is part of the same job object as eclipse.exe, starter.exe, etc. (Having studied the code in starter.cpp, I would say that this was *not* the developer's intention)
7. If desired, continue to check the "DebugOutput" messages:
 - compile starter.exe using the DEBUG_MONITOR compiler directive
 - Open DebugView provided by Sysinternals (http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx)
 - Repeat the above steps of starting a debugging session
 - Search for "Cannot assign process" to see the reported error