Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

error 487 (after a week of using) #123

Closed
imz opened this Issue Jun 15, 2013 · 17 comments

Comments

Projects
None yet
4 participants

imz commented Jun 15, 2013

After about a week of using https://msysgit.googlecode.com/files/Git-1.8.3-preview20130601.exe , today the commit command in Git GUI started to fail: it results in error 487.

Cf. older reports: https://code.google.com/p/msysgit/issues/detail?id=176 , https://code.google.com/p/msysgit/issues/detail?id=133 .

Does it have something to do with Cygwin? But I haven't installed Cygwin there, only Git for Windows.

Is there any hope that the problem with Git hitting this error suddenly will be fixed in the Git for Windows package (without any intervention from the user)?

Owner

patthoyts commented Jun 18, 2013

This needs at minimum a stack trace from someone that can reproduce the fault. Unfortunately that means you. This is unlikely to be due to git-gui. If you run got gui with the --trace option it will show the Tcl console window and display the actual git commands that get run. That can show you what git commands you can use to reproduce the fault in a debugger. You will have to rebuild git (which just means downloading and running the net installer to get setup). Then you can run the faulting git command under gdb and try for a stack trace. If you were ok for a week and now it is failing - clearly something local has changed and is causing a conflict. Loading the wrong library could do that - check with a minimal PATH set. ie just the git\cmd and windows directories and see how that helps..

imz commented Jun 20, 2013

A similar situation described: http://stackoverflow.com/q/11419700/94687 .

Unfortuantely, this happens on a mchine of a collegue of mine, so it'll take time before I can get at it.

There must have been no Cygwin ever installed on this machine.

imz commented Jun 20, 2013

http://stackoverflow.com/a/16654689/94687: I've had this problem as well. I've solved it with http://support.code-red-tech.com/CodeRedWiki/VirtualAllocPointerNull . Apparently this is caused by some feature, and replacing the dll fixes it for most people.

http://support.code-red-tech.com/CodeRedWiki/VirtualAllocPointerNull: This is a problem that affects a tiny minority of customers, and depends on what other applications they are running at the same time. This is caused by a feature in the MSYS binaries that we use to provide the the build environment for the product.
If this happens, you can replace the file
<install_dir>\msys\bin\msys-1.0.dll
with the file in the attached zipfile. msys-1.0.zip
Note that this does not fix the problem, rather it moves DLL base address. Unfortunately, it is possible the error may occur with this replacement DLL too, again depending on what other applications are running.

What a mystic feature of MSYS that can suddenly cause an error!

Owner

patthoyts commented Jun 22, 2013

More specifically this has been rebased from 0x68000000 to 0x30000000. This can be replicated on the binary we actually ship by running rebase -b 0x30000000 msys-1.0.dll. We don't ship rebase but it is included in the msysGit build environment.

maoueh commented Jul 10, 2013

Just reporting here to add some information. I had use the full installer for months (something like 4 or 5, maybe 6) and suddenly, from tuesday to wednesday, it stop working with the dreaded VirtualAlloc null pointer problem.

I was really surprised to encounter the problem because I didn't have done anything special the day before it started crashing. I shutdown my compute as usual and when arriving at work the next morning, I was unable to start my terminal anymore.

Some have say the a Windows update could have triggered this, however, on my machine, the last windows update was performed on 19/06/2013 so it cannot be the case, at least for me. There is some updates pending however. I will update and reboot to see what happens as I read that it could solve the problem. After that, I will rebase my DLL if it does not fix my issue.

Information on my system:

  • Windows 7 Professional SP1 64 bits
  • Msysgit full installer (version 1.8+, I don't remember which one exactly, how can I check?).

Base address reported on the error message is BaseAddress 0x68560000. Not sure if it's the preferred base address set for msysgit-1.0.dll.

Will report with what I have done to fix the problem.

Regards,
Matt

maoueh commented Jul 10, 2013

So, I first tried with a simple reboot and sadly, it fixed the problem right away. I only did a simple reboot nothing else.

In the end, I really can't say what happen for the error to appear then disappeared right away. One of the hypotheses I can come with would be the order in which I started my system. Usually, I open my terminal first, but today, I started some program before (Thunderbird then Eclipse). I tried to reproduce but was not able to.

If I ever encounter the problem again, I will report back here with more information. We shall find the real culprit and solution one time.

Owner

dscho commented Jul 10, 2013

@maoueh this comment has the common solution: #123 (comment) (you usually have to try a couple of different addresses before it works).

I am afraid that I have not found a better solution, even after years. The problem is that msys-1.0.dll cannot be relocated to a different runtime location dynamically due to Windows-specific limitations. And if other loaded DLLs already occupy that location, msys-1.0.dll will not be able to load.

maoueh commented Jul 10, 2013

@dscho I understand. But there must a final solution for this. Maybe it cannot be applied yet (or never), but there is tons of DLL loading code out there, so I cannot imagine there is not a clear solution.

Don't interpret this as an argument from me to fix the problem right away. There is workarounds that work well and this problem does not affect everyone. Since everything is documented and a simple Google search leads to those solutions, there is no hurry to work on this or to even just put time on it. I'm sure time can be well spent elsewhere where it will have greater impact.

Keep up the good work guys :)

imz commented Jul 23, 2013

Yes, that's suprising that other DLLs usually are OK, but this one sometimes fails. What does explain the difference between msys and other DLLs?..

Owner

dscho commented Jul 23, 2013

@imz MSys needs to be fixed in memory. The problem is that Windows has not the faintest concept of a proper fork() (which starts a new process from the current state, memory, file descriptors, etc). So MSys has to emulate it by creating a completely new process from scratch and try its best to reinstate the memory, file descriptors, and all the rest.

imz commented Jul 23, 2013

@dscho Thanks for the explanation! I've been very interested about it!

Owner

dscho commented Dec 30, 2013

@imz interested enough to try your own hand at that final solution you must have? ;-)

imz commented Dec 30, 2013

@dscho I'm almost always very interested at trying "my own hand" at a programming problem I encounter. In this case, I was interested very much in an explanation, too. Now you gave it. And now, when I know it's about reimplementing a system call or working it around, I have less interest. Especially, in the first way. I like generic solutions, so if we go the first way, we'd aim at a better Unix emulator under Windows -- here that would manage processes on its own, but also allow tight integration with Windows FS and GUI (or other Windows processes which would be the Git GUI tools)... Sounds quite complex. BTW, I've heard that Windows had POSIX compatibiliyy layer, so I'm a bit surprized there is no proper fork...

As for the latter way... Well, I've been thinking of libgit2 which is said to work under Windows, so one might try ro create the Git UI tools ontop of it, and have no stability problems...

Do you suggest to rewrite msysgit so that it needs no proper fork? I'm not ready to put my efforts into this in my free time, and also I always use Linux, and this averts me from Windows programming.

I wonder though how other crossplatform projects overcome the problem with fork. Perhaps, all they use really is the combination of fork and exec, and this notion mist work under Windows, I guess. Does Git really needs a fork with duplicating the process memory etc.?

FWIW I haven't written here that "I must have a solution". If your "you" is to be read collectively, I don't see why it is not "we". :-)

Owner

dscho commented Dec 30, 2013

@imz Windows has definitely no POSIX compatibility layer. To the contrary, hence the existence of Cygwin (and MSys, a minimal offspring of Cygwin).

As to the "I must have a solution", I misread your comment: it only says: But there must a final solution for this.

As to why Git relies on fork(): Git is multi-platform software. In fact, upstream git.git does not care all that much about Windows, and given all the complications we have to address, I sometimes long for that luxury, too.

To conclude this issue, I think we pretty much established that the status quo is good enough, so let's close the issue, at least for now.

@dscho dscho closed this Dec 30, 2013

imz commented Dec 30, 2013

It wasn't a comment of mine :-)

As for Git's use of fork: I haven't looked closer, but does it make use of fork without exec? Otherwise, perhaps, it could be implemented with spawn in Windows.

Also to test the thing, we must know how to reproduce the error in any new msysgit binary.

I don't feel that the status quo is ok, because whenever we suggest someone to use git under windows, he might run into this problrm and not have the skills to find the "solution", but I can't do much about this.

Owner

dscho commented Dec 30, 2013

@imz Bah! You're correct, I was referring to another comment than yours! My fault, sorry, and thanks for pointing that out.

As to the fork() thing: our work in Git for Windows -- to be precise, it was mostly Johannes Sixt's work who finished the initial MinGW port where I left off -- proves that a complete fork() emulation is not needed. See run-command.c for details.

As to the status quo: in contrast to upstream git.git, we are not blessed with an abundance of volunteers here in the Git for Windows project. In fact, we get way too many requests, and most of the actual contributors are just way to say "no" all the time.

Further, in this particular case, the problem is actually not caused by Git, nor by the libraries used by Git, but rather by the MSys programs we need to use (which do require a proper fork() emulation).

So even if you are willing to spend time on solving this issue, you would have to do so in the MSys (or MSys2) context, not in Git for Windows (although, technically, you could try patching the msys-1.0.dll library we patched ourselves a couple of times due to upstream MSys not being able to accommodate our patches fast enough for us to use upstream's vanilla msys-1.0.dll).

imz commented Dec 31, 2013

Thanks for the further explanation and the link to code! That's interesting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment