Menu
▾
▴
[MinGW-notify] [ mingw-Bugs-3075616 ] GUI installer fails - CreateProcess error - Windows 7
|
From: SF/projects/mingw n. l. <min...@li...> - 2010-10-15 14:54:37
|
Bugs item #3075616, was opened at 2010-09-25 19:18 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3075616&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lou Hafer (lou-oss) Assigned to: Keith Marshall (keithmarshall) Summary: GUI installer fails - CreateProcess error - Windows 7 Initial Comment: Downloaded mingw-get-inst-20100909.exe 2010.09.25 and ran it. Selected additional packages, requested refresh of package lists. Installer ran fine for a while, completed download of updated package lists, then died with error Unable to execute file D:\MinGW\bin\mingw-get.exe CreateProcess failed; code 32 The process cannot access the file because it is being used by another process. The CLI installer clearly works --- I was able to use mingw-get to complete the installation from the command line, and went on to successfully build Coin-OR software, so the install seems to be correct. Looks like just a bug in the installer. Seems repeatable. I tried a second, independent install while trying to sort out a Coin-OR bug report, saw the exact same behaviour. System is Windows 7 64-bit running on Intel Core i7. All Windows patches installed, to my knowledge. ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2010-10-15 14:54 Message: >> "The DeleteFile function marks a file for deletion on close. > > If that actually works as advertised, it could obviate > the need for a separate last rites process, Hmm. Reviewing the link cited, immediately before that quote it says: "The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file." Even after the rename, the files remain open by virtue of them being the exe and dll in use by the process trying to delete them. A quick experiment: $ cat foo.c #include <conio.h> #include <stdio.h> #include <windows.h> int main() { rename( "foo.exe", "foo.exe~" ); DeleteFile( "foo.exe~" ); printf( "Press any key to continue..." ); while( getch() == -1 ); return 0; } confirms that (on my Vista box) the outcome is that DeleteFile fails; the file is not marked for deletion on close, as evidenced by the continued existence of foo.exe~ after process termination (when it should be closed). Yet another example of contradictory, misleading and just downright incorrect info in MSDN documentation -- and in this case, the contradiction is between two immediately adjacent paragraphs on the same page! I guess we'll just have to stick with the separate lastrites process -- at least that does perform the clean up as intended. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2010-10-15 13:48 Message: > You're allowed to rename the open file. We already do that; this is how the tilde qualified files appear. > You can then mark the renamed file with > delete on close. > > From http://msdn.microsoft.com/en-us/library/aa363915(VS.85).aspx > we see: > > "The DeleteFile function marks a file for deletion on close. > Therefore, the file deletion does not occur until the last handle > to the file is closed. Subsequent calls to CreateFile to open > the file fail with ERROR_ACCESS_DENIED." Thanks, Earnie. If that actually works as advertised, it could obviate the need for a separate last rites process, (but it begs the question "why doesn't the unlink() API do likewise?"; after all, that would make it exactly analogous to the POSIX unlink() behaviour. I'll need to play with it, to see what mileage we can achieve from it. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2010-10-15 13:40 Message: > ... > The "fault" is that the file are named "mingw-get.exe~" during install > finish procedure. Which in turn is not a fault per se, I suspect. This isn't the bug; indeed neither is it a fault. In fact, this is by design; (see below). > If one copy the file "mingw-get.exe~" to mingw-get.exe during install it > works fine. By doing this, you are simulating what mingw-get would do itself, when a scheduled upgrade of itself is installed; you are potentially interfering with this normal upgrade action, possibly corrupting your installation database. > ... > > IFF this is coherent one could might add a, rather ugly fix by, manual > copy of the file mingw-get.exe~ to mingw-get.exe on the appropriate > times of install sequence. The workaround I have in mind is to ensure that the rename to revert to the original names occurs just before the mingw-get process itself terminates, rather than merely delegating the task to the exec()ed lastrites process. > NB! The times of when to copy rename the file as mentioned above > are observation based guesswork. My analysis, OTOH, is based on intimate and authoritative knowledge of how the process actually works. So, to dispel further speculation: * To facilitate self-upgrade, mingw-get renames its own exe and dll, (by appending a tilde to the names). This is necessary because Windows will not permit replacement of these files while they are in use by the running process, but it will allow them to be renamed, so they no longer interfere with installation of new versions. Ultimately, this rename step should be triggered by a pre-remove action script associated with the mingw-get package itself, but that capability isn't supported yet, so in the interim, it is performed up-front, and unconditionally, regardless of scheduled upgrades. * At termination, if the two renamed files were replaced by new versions, then the old files should be deleted, but the running mingw-get process cannot do this because both files remain in use, by the process itself, and Windows will not allow deletion of in-use files. Thus the removal is delegated to the lastrites process, which also, if no replacements were installed, attends to renaming the tilde qualified files back to their original names. This lastrites delegation is unavoidable, and will remain so regardless of how the original files are moved out of the way in any final solution. Now, to set the lastrites process in motion, mingw-get's final action is to call execl(), to invoke lastrites.exe; this is where the Microsoft bug bites: when execl() is called, the calling process terminates immediately, passing control back to its parent process, which then immediately proceeds to its next action. Although the exec()ed process is invoked as intended, the original parent process is not aware of this, and no mechanism seems to be available to cause it to wait for the exec()ed process to complete, (as it would automatically, with a POSIXly correct execl() implementation, if it was waiting for the process which called the execl() function). I am reasonably confident in my diagnosis of this problem. It will take me some finite time to develop the workaround. Thank you for your interest, but until I can complete and we can evaluate this workaround, further speculative diagnosis isn't really helpful. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2010-10-15 13:30 Message: You're allowed to rename the open file. You can then mark the renamed file with delete on close. >From http://msdn.microsoft.com/en-us/library/aa363915(VS.85).aspx we see: "The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED." ---------------------------------------------------------------------- Comment By: Z0l0ft (z0l0ft) Date: 2010-10-15 10:57 Message: Partially same on XP. End with error: { Unable to execute file: c:\mingw\bin\mingw-get.exe CreateProcess failed; code 2. The system cannot find the file specified } The "fault" is that the file are named "mingw-get.exe~" during install finish procedure. Which in turn is not a fault per se, I suspect. If one copy the file "mingw-get.exe~" to mingw-get.exe during install it works fine. It has to be done twice: 1. When the finish procedure starts 2. After mingw-get\data xml files has been downloaded. If one do not do this, the setup app finish by renaming mingw-get.exe~ to mingw-get.exe so it looks like it was there... Have not been able to locate the cause, but keithmarshall's comment look promising. - IFF this is coherent one could might add a, rather ugly fix by, manual copy of the file mingw-get.exe~ to mingw-get.exe on the appropriate times of install sequence. NB! The times of when to copy rename the file as mentioned above are observation based guesswork. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2010-10-09 21:37 Message: Thank you all, for the reports. I suspect what you are seeing is a race condition, (caused by what I consider to be a serious defect in Microsoft's exec() implementation), resulting from mingw-get-inst attempting to start a new instance of mingw-get, before the lastrites process exec'ed by the preceding instance has released the executable for reuse; that some of you see error 2, while the OP saw error 32 would fit, depending on how far lastrites had progressed at the time of the CreateProcess() call for the new mingw-get instance. I have an idea for a workaround for this Microsoft bug, and will pursue it. ---------------------------------------------------------------------- Comment By: Greg Gursky (bitspring) Date: 2010-10-08 23:44 Message: I've encountered the code 2 variant on Win 7 64-bit launched as Administrator but only if I select "Download latest repository catalogs". I chose the following packages: C, C++, MSYS Basic System, MinGW Dev Toolkit --- Unable to execute file: C:\MinGW\bin\mingw-get.exe CreateProcess failed; code 2. The system cannot find the file specified --- The file is there. ---------------------------------------------------------------------- Comment By: Steven Borley (sjborley) Date: 2010-10-08 11:00 Message: I'm having the same problem on Windows Vista using mingw-get-inst-20100909.exe Dialogue box gives... Unable to execute file: C:\MinGW\bin\mingw-get.exe CreateProcess failed; code 2. The system cannot find the file specified ---------------------------------------------------------------------- Comment By: Leif W (warp9pnt9) Date: 2010-10-04 00:50 Message: Same system and error as above. Windows 7 64-bit on an AMD Athlon X2 6000+. Also I got code 2, not code 32. Also tried running from an Administrator Command Prompt. Download latest repository catalogues Install to C:\MinGW Selected packages: C, C++, MSYS Basic System, MinGW Dev Toolkit The mingw-get.exe file is there. While the installed is doing "something" (after it retrieves the .xml files), I notice the dll file has a tilde after it. C:\MinGW\libexec\mingw-get\mingw-get-0.dll~ Around the time the error occures, it is renamed without the tilde. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2010-10-02 21:45 Message: Ditto - Win 7 64 bit Intel i5 - exact same error message as in previous comment. I added C:\MinGW\bin to the user path and re-running the installer with the same outcome. I tried running mingw-get.exe directly but nothing happened that I could see. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2010-10-01 08:13 Message: Same here. Windows 7, some AMD processor. Except my error is: Unable to execute file C:\MinGW\bin\mingw-get.exe CreateProcess failed; code 2 The system cannot find the file specified. However the file IS in the location mentioned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3075616&group_id=2435 |