Rozszerzenia Git: do wczoraj wszystko działało dobrze.
Ale nagle pojawia się ten błąd, gdy próbuję pobrać niektóre repozytoria git extensions
C:\Program Files\Git\bin\git.exe pull --progress "origin"
Done
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x68560000, RegionSize 0x390000, State 0x10000
C:\Program Files\Git\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0
Dzieje się tak dla wszystkich repozytoriów, które sklonowałem. Ale mój git bash działa dobrze. Nie mam pojęcia, co się dzieje. Masz pomysł, dlaczego tak się dzieje?
git
cygwin
git-extensions
Uchia Itachi
źródło
źródło
Odpowiedzi:
Cygwin korzysta z trwałych sekcji pamięci dzielonej, które mogą czasami zostać uszkodzone. Objawem tego jest to, że niektóre programy Cygwin zaczynają zawodzić, ale inne aplikacje pozostają bez zmian. Ponieważ te sekcje pamięci współużytkowanej są trwałe, często konieczne jest ponowne uruchomienie systemu , aby je usunąć, zanim problem zostanie rozwiązany.
źródło
Miałem ten sam problem. Znalazłem rozwiązanie tutaj http://jakob.engbloms.se/archives/1403
Dla mnie rozwiązanie było nieco inne. To było
Przed zmianą bazy bibliotek DLL upewnij się, że nie jest on używany:
I wykonaj kopię zapasową:
Jeśli polecenie rebase nie powiedzie się z czymś takim jak:
Musisz wykonać następujące czynności w kolejności:
W przypadku jakichkolwiek problemów uruchom polecenia jako Administrator
źródło
tl; dr: Zainstaluj 64-bitową wersję Git dla Windows 2 .
Szczegóły techniczne
Ten objaw sam w sobie nie ma nic wspólnego z bazami obrazów plików wykonywalnych, uszkodzonymi sekcjami pamięci wspólnej Cygwin, sprzecznymi wersjami bibliotek DLL itp.
To kod Cygwina, który nie przydziela ok. 5 MB dużej pamięci dla swojego sterty pod tym stałym adresem 0x68570000, podczas gdy najwyraźniej dostępna była tam tylko dziura o wielkości ok. 2,5 MB. Odpowiedni kod można zobaczyć w źródle msysgit .
Dlaczego ta część przestrzeni adresowej nie jest wolna?
Może być wiele przyczyn. W moim przypadku były to inne moduły załadowane pod adres powodujący konflikt:
Ostatni adres powinien wynosić około 0x68570000 + 5 MB = 0x68C50000, ale niektóre biblioteki DLL związane z WOW64 są ładowane od 0x68810000 w górę, co blokuje przydział.
Ilekroć istnieje wspólna biblioteka DLL, Windows ogólnie próbuje załadować ją pod tym samym adresem wirtualnym we wszystkich procesach, aby zaoszczędzić trochę przetwarzania relokacji. To tylko kwestia pecha, że te elementy systemu, ale jakoś załadowanego w konflikcie adres ten czas .
Dlaczego w twoim Git jest Cygwin?
Ponieważ Git jest bogatym pakietem składającym się z kilku poleceń niskiego poziomu i wielu przydatnych narzędzi i głównie opracowanych na systemach uniksopodobnych. Aby móc go zbudować i uruchomić bez masywnego przepisywania, potrzebuje przynajmniej częściowego środowiska uniksowego.
Aby to osiągnąć, ludzie wymyślili MinGW i MSYS - minimalny zestaw narzędzi do budowania programów w systemie Windows w sposób podobny do Uniksa. MSYS zawiera również bibliotekę współdzieloną
msys-1.0.dll
, która pomaga w niektórych problemach ze zgodnością między dwiema platformami w czasie wykonywania. Wiele z nich zostało zaczerpniętych od Cygwina, ponieważ ktoś już musiał rozwiązać te same problemy.Więc to nie Cygwin, to biblioteka uruchomieniowa MinGW, która zachowuje się tutaj dziwnie.
W Cygwin ten kod faktycznie się bardzo zmienił od czasu, co jest w MSYS 1.0 - ostatnia wiadomość zatwierdzenia dla tego pliku mówi „Importuj Cygwin 1.3.4”, która pochodzi z 2001 roku!
Zarówno obecny Cygwin, jak i nowa wersja MSYS - MSYS2 - mają już inną logikę, która, mam nadzieję, jest bardziej niezawodna. To tylko stare wersje Git dla Windows, które zostały zbudowane przy użyciu starego, zepsutego systemu MSYS.
Czyste rozwiązania:
Hacky rozwiązania:
PATH
może czasami działać, ponieważ mogą istnieć różne wersjemsys-1.0.dll
różnych wersji Git lub innych aplikacji opartych na MSYS, które mogą używać innego adresu, innego rozmiaru stosu itp.msys-1.0.dll
może być stratą czasu, ponieważ 1) będąc biblioteką DLL, ma już informacje o relokacji i 2) „w żadnej wersji systemu operacyjnego Windows nie ma gwarancji, że (...) biblioteka DLL zawsze będzie ładować w tej samej przestrzeni adresowej” w każdym razie ( źródło ). Jedynym sposobem, w jaki może to pomóc, jest to, żemsys-1.0.dll
sam ładuje się pod adres powodujący konflikt, którego następnie próbuje użyć. Najwyraźniej czasami tak jest, ponieważ właśnie tak robią faceci Git dla Windows w systemach 32-bitowych .msys-1.0.dll
plik binarny, aby użyć innej wartości_cygheap_start
i to natychmiast rozwiązało problem.źródło
cmder/vendor/git-for-windows
katalogu i zmieniłem nazwę starego folderu nagit-for-windows-x86
. Jeśli otworzyszcmder/vendor/git-for-windows
, zobaczysz foldermingw32
, który jest wskazówką, że używasz 32-bitowego. W Git x64 zobaczysz foldermingw64
.Bardzo prosta wersja rozwiązania bazowego:
Przejdź do folderu, w którym zainstalowany jest git, takiego jak:
Przytrzymując klawisz Shift i klikając prawym przyciskiem myszy folder, powinieneś być w stanie otworzyć wiersz polecenia jako administrator stamtąd (dzięki https://stackoverflow.com/users/355389/darren-lewis za ten komentarz),
Następnie uruchomić:
Naprawiłem to, gdy podejście restartu nie działało.
Mam nadzieję, że to pomoże.
źródło
Po aktualizacji do git1.8.5.2 zobaczyłem ten sam komunikat o błędzie:
Po prostu wyszukaj wszystko
msys-1.0.dll
na swoimC:\
dysku i spraw, aby ten używany przez Git był na pierwszym miejscu.Na przykład w moim przypadku po prostu zmieniłem kolejność:
Sprawiając, że ścieżka Git
C:\prgs\git\PortableGit-1.8.5.2-preview20131230\bin\
jest na pierwszym miejscu%PATH%
, komunikat o błędzie zniknął.Nie ma potrzeby ponownego uruchamiania ani nawet zmiany sesji DOS.
Po
%PATH%
zaktualizowaniu w tej sesji DOS polecenia git po prostu działają.Pamiętaj, że zarówno Carmbrester, jak i Sixto Saez zgłaszają poniżej (w komentarzach) konieczność ponownego uruchomienia w celu rozwiązania problemu.
Uwaga: po pierwsze, również usuwając dowolny
msys-1.0.dll
, taki jak jeden w%LOCALAPPDATA%
źródło
Jeśli ponowne uruchomienie nie rozwiąże problemu (jak sugeruje odpowiedź Grega Hegwilla), sprawdź PATH pod kątem sprzecznych instalacji msys-1.0.dll (i ewentualnie innych powiązanych bibliotek DLL).
W mojej szczególnej sytuacji instalacja msys przez MinGW ma kopię tej biblioteki DLL w swoim
bin
katalogu (<MinGW_Install_Path>\msys\1.0\bin
) i została wymieniona w ŚCIEŻCE.cmd
Katalog Gita był wymieniony w ŚCIEŻCE, alebin
nie był. (Wersja Gys msys-1.0.dll znajduje się wbin
katalogu. Najwyraźniej domyślna instalacja MSys-Git nie dodaje jejbin
do PATH.)Tymczasową poprawką było dodanie
bin
katalogu Gita do ŚCIEŻKI, aby pojawił się przed ścieżkami MinGW. (Trwała poprawka prawdopodobnie będzie polegać na rozwiązaniu konfliktów ścieżek między msys MinGW a Git i / lub usunięciem zduplikowanych instalacji msys.)źródło
Chcę tylko podzielić się tutaj swoim doświadczeniem. Ten sam problem napotkałem podczas kompilacji krzyżowej dla platformy MTK na 64-bitowym komputerze z systemem Windows. MinGW i MSYS są zaangażowane w proces budowania i ten problem pojawił się. Rozwiązałem to, zmieniając
msys-1.0.dll
plik. Anirebase.exe
ponowne uruchomienie systemu nie działało dla mnie.Ponieważ na moim komputerze nie ma zainstalowanego programu rebase.exe. Zainstalowałem cygwin64 i wykorzystałem
rebase.exe
wnętrze:Mimo że ponowne bazowanie wydawało się udane, błąd pozostał. Następnie uruchomiłem
rebase
polecenie w terminalu Cygwin64 i dostałem błąd:Później spróbowałem kilka adresów, ale żaden z nich nie działał. Skończyło się na zmianie
msys-1.0.dll
pliku i to rozwiązało problem.źródło
Wpadłem na to dzisiaj. Kierowany odpowiedzią Grega Hewgilla, spojrzałem na uruchomione procesy w moim systemie, aby sprawdzić, czy coś się „utknęło” lub czy inni użytkownicy byli zalogowani na maszynie, robiąc cokolwiek z git. Następnie uruchomiłem cygwin (zainstalowany osobno) na tym konkretnym komputerze. Uruchomił się dobrze. Zamknąłem go, a następnie ponownie wypróbowałem rozszerzenia Git (próbowałem operacji ściągania) i zadziałało. Nie jestem pewien, czy uruchomienie cygwina wyczyściło coś, co zostało udostępnione, ale po raz pierwszy napotkałem ten błąd i wydawało mi się, że to naprawiło.
źródło
Miałem ten sam problem po awarii i aktualizacji systemu Windows 8.0 na msys git 1.9. Nie znalazłem żadnego msys / git na mojej ścieżce, więc właśnie dodałem go do ustawień envinroment lokalnych użytkowników Windows. Działa bez ponownego uruchamiania.
Zasadniczo, podobnie jak RobertB, ale nie miałem żadnych git / msys na mojej ścieżce.
Btw:
Próbowałem użyć rebase -b blablabla msys.dll, ale miałem błąd „ReBaseImage (msys-1.0.dll) nie powiodło się z ostatnim błędem = 6”
jeśli potrzebujesz tego szybko i nie masz czasu na debugowanie, zauważyłem, że „Git Bash.vbs” w katalogu Git pomyślnie uruchamia powłokę bash.
źródło
c:\Program Files (x86)\Git\bin
do ścieżki i teraz jestem złoty.Ten błąd występuje bardzo rzadko na moim komputerze z systemem Windows. W końcu zrestartowałem komputer i błąd zniknął.
źródło
Napotkałem ten problem z budynkiem LPCEXpresso. Jeśli masz C: \ MinGW \ bin w ŚCIEŻCE. w jakiś sposób musiałem go usunąć, aby pozbyć się tego problemu, ponieważ niektóre inne oparte na MinGW również
źródło
Aby rozwiązać ten problem, po prostu pozwalam Tortoise Git zainstalować swoją aktualizację.
źródło
c: \ msysgit \ bin> rebase.exe -b 0x50000000 msys-1.0.dll
źródło
Usuwanie starej wersji% USERPROFILE% \ AppData \ Local \ SourceTree \ app-xxx działało dla mnie. Nie jestem pewien, jak to było połączone z git z wiersza poleceń ...
źródło