Menu
▾
▴
#2026 Installer reports errors on Win7 (64bit) and subsequently crashes.
closed
None
Bug
fixed
Unknown
False
2013-09-10
2013-09-03
No
While trying to install MinGW on Windows7 64bit the log of the installer reports serveral errors, indicating that files cannot be copied. After a while the installer crashes.
I have observed this behaviour on two different Win7 machines.
This isn't enough detail. I use a Windows 7 64bit laptop with an i7 core chipset and have experienced nothing like this.
What antivirus are you using? Could it be a factor? What other software do you have installed? Could any of the device drivers be a factor? And for goodness sakes supply the text of the log; we're not mind reading magicians.
I experienced the same behaviour. Running Windows 7 64bit i3 with 6GB RAM.
The Installer seem to run almost to the end. Then it crashes, windows give the only option to close application. Upon restarting, no packages have been installed. Rerunning causes the same behaviour only difference that the log spits out thousands of "write failed" errors before it crashes, probably due to that most files are allready installed from the previous installation attempt.
The problem does not occur when only installing msys base. Only when installing g++ (the only two components I tried to install)
Other things tried:
- Registry cleanup and rebooting, does not help.
- Checking memory comnsumption during install - no problem, total memory consumption is less than 25% during whole installation.
- Turning off Virus scanner - doesn't help
Since I can't find any logfile saved anywhere I'll provide a screenshot of what the log says during the crash.
Olof,
This looks like file ownership and perhaps ACL issues. In other words, an environment issue not related to mingw-get.
I think Anti-Virus can't be an issue. I don't use any on the Win7 virtual machine, where I tried it as well.
I could not get at the text of the log as the application crashed. Upon the crash the text / log output window is inaccessible for selection.
I will try to attach a screenshot. I just observed the same behavior as Olof pointed out that only installing msys-base works fine.
Upon installation of mingw32-gcc-g++ the problems occurs. The log reads for example like this:
mingw-get: *** ERROR *** cannot replace existing file
mingw-get: ** ERROR *** C:\Mingw\/mingw32/lib/gcc/mingw32/4.8.1/include/c++/ext/pb_ds/detail/gp_hash_table_map_/constructor_destructor_fn_imps.hpp: extraction failed*
Similar lines occur for a huge amount of files each. The sections I can see all deal with the gcc includes like above.
The file above already exists exactly as given in the path.
I can provide a core dump. (I just don't know how the provide the 78Mb file.)
Last edit: Thorsten Schroeteler 2013-09-04
Thorsten, why is it trying to replace versions of itself? But again, file ownership and maybe ACL issues? I suppose it could be the package itself but I just gave a delete and install again a try with no problems.
I tried the option for shortcuts "...just for me (the current user)" instead of "...for all users *..." and then it completes without crashing (the overwrite problem logs still occurs but thats probably not related to the crash)
I still suspect its a bug though when running with the "...for all users *..." since it crashes although I am running my Admin account (Real Main Admin on private laptop hence not a fake Admin account created by som IT-department)
I can reproduce this, consistently, on a Win7 32-bit VM, installing into a completely clean sandbox. 32-bit vs. 64-bit, shortcut creation, admin vs. user privilege, file ownership, ACL, are all red herrings.
There are two issues at play here. Bug [#2030] is Earnie's to resolve, but that shouldn't be crashing mingw-get; neither does it, when running the CLI client. I'll need to investigate further, but I suspect that the sheer volume of diagnostic output resulting from [#2030] is overwhelming the GUI client's diagnostic message handler, exposing a hitherto undetected buffer overrun issue.
Related
Issues: #2030
Running an unstripped build under GDB confirms a buffer overrun, but not as a direct consequence of the volume of diagnostics. It was actually the result of a diagnostic message exactly filling the output buffer, without leaving space for the terminating NUL, but without triggering the buffer wrapping logic, so causing the NUL to overrun by exactly one byte, (which of course is enough to trash the heap, and cause a crash).
I have a fix, which I'll try to get out later this week. I'd also like to fix the other issue this has revealed; when a file collision occurs, and mingw-get declines to overwrite the offender, it should not record in its manifest that it did. However, I will not delay the buffer overrun fix, if the manifest issue looks like it may need more than a quick fix.
Both the buffer overrun issue, and the manifest recording issue, (which turned out to be trivial), are fixed in mingw-get-0.6.1-beta-20130910-1