Ответ 1

Один из моих коллег имеет аналогичные ошибки при открытии терминала из SourceTree (Mingw32), а также получил ошибки при попытке pull, rebase и т.д. (что-то не локальное). Он решил это, удалив Sourcetree, используя CCleaner для очистки своих реестров (не уверен, требуется ли это), перезагрузился и снова установил Sourcetree.

Я знаю, что это немного отличается от проблемы, описанной OP, но она все равно может быть разрешена путем повторной установки и очистки реестров, и это может также помочь будущим людям найти этот вопрос с проблемой Sourcetree (например, Я сделал).

Edit: У другого коллеги тоже была проблема, и ему удалось исправить ее только перезагрузкой без какой-либо переустановки или использования CCleaner.

Ответ 2

От https://chromium.googlesource.com/chromium/src/+/master/docs/cygwin_dll_remapping_failure.md

Обработка повторяющихся сбоев rebaseall, позволяющих перепроверить cygwin

Иногда библиотеки DLL, над которыми cygwin не имеет контроля, отображаются в cygwin процессов в местах, выбранных cygwin для своих библиотек. Это прежде всего было связано с антивирусными DLL. Когда это происходит, cygwin должен быть проинструктирован во время rebase, чтобы избежать области памяти, в которой отображается эта DLL.

Фон

Некоторые предпосылки для этого доступны на http://www.dont-panic.cc/capi/2007/10/29/git-svn-fails-with-fatal-error-unable-to-remap/

Из-за семантики forex unix (предположительно) библиотеки cygwin должны быть отображается в том же месте как у родителя, так и у ребенка вилки. Все Библиотеки cygwin имеют в себе подсказки о том, где они должны быть сопоставлены в адресном пространстве процессов; если следовать этим намекам, каждый библиотека будет отображаться в том же месте в обоих адресных пространствах. Однако Windows отлично справляется с отображением DLL в любом месте адресное пространство; подсказка не считается контрольной. Перенос ошибка возникает, когда начинается процесс cygwin и одна из его библиотек не может быть сопоставлена ​​с местоположением, указанным его подсказкой.

/usr/bin/rebase all изменяет подсказки DLL для всех cygwin библиотек, чтобы не было межбиблиотечных конфликтов; он делает это выбирая смежную, но не перекрывающуюся структуру библиотеки, начиная на базовом адресе и работает вниз. Этот процесс гарантирует, что нет конфликтов внутри cygwin, но не может иметь дело с конфликтами с внешние DLL файлы, которые находятся в адресных пространствах процесса cygwin (например, антивирусные DLL).

Чтобы справиться с этим случаем, вам нужно выяснить, что проблематично библиотека non-cygwin находится там, где она находится в адресном пространстве, и перебазируйте все, чтобы никакие подсказки cygwin не отображали библиотеки в этом месте.

Подробнее

• Загрузите исполняемый файл ListDLLs из sysinternals
• Запустите его как администратор, пока выполняются некоторые команды cygwin.
• Отсканируйте вывод для процесса cygwin (идентифицируемый по команде) и для DLL в этом процессе, которые не похожи на DLL cygwin (например, AV). Заметка расположение этих библиотек (обычно будет только один).
• Выберите адресное пространство ниже его начального адреса.
• Закройте все процессы cygwin.
• Запустите командную оболочку Windows как администратор
• cd в \cygwin\bin
• Запустите ash /usr/bin/rebaseall -b <base address> (Эта команда также может принимать -v, если вы хотите увидеть макет DLL.)

Это должно устранить проблему.

Сбой rebaseall

Если вы выберете базовый адрес, который слишком низок, вы можете получить сломанный cygwin установить. Вы можете переустановить его, запустив cygwin setup.exe снова, и на страницу выбора пакета, щелкнув запись "Все", чтобы переустановить. Возможно, вам придется сделайте это дважды, так как вы можете получить ошибки при первом переустановке прохода.

Ответ 3

Я недавно сталкивался с подобными проблемами. Я не смог определить причину, будь то из-за недавнего обновления Windows7 или обновления в последнем cygwin. Я в жесткой контролируемой корпоративной среде с ограниченными правами, множеством антивирусных программ и зашифрованных дисков. В настоящее время я использую 32-разрядный Cygwin.

Проблемы для меня начались после того, как я установил пакеты Git и Git -Svn, которые требовали Perl и обновили различные другие пакеты Cygwin.

Rebasing с помощью rebase-trigger или rebaseall не разрешил проблему для меня. Кроме того, при повторной установке и настройке неоднократно возникали ошибки в post-install pahse при попытке выполнить сам rebase.

Мой первый успех был за счет понижения Perl до предыдущей версии, т.е. до 5.22.1.2 из 5.22.2.1. Через пару недель ошибка вернулась, возможно, после принудительного обновления и перезагрузки Windows.

Мой последний успех был достигнут, игнорируя dash/rebaseall script и запуская rebase.exe прямо следующим образом: -

• Создайте файл, в котором перечислены все файлы cygwin.dll в каталоге /bin, за исключением cygwin1.dll и cyglsa.dll, т.е. $ cd /bin $ ls -1 *.dll | egrep -v '(cygwin1|cyglsa).*\.dll' >rebasedlls.txt
• Закройте все терминалы cygwin, если у вас есть какие-либо службы, которые используют cygwin, чтобы они были остановлены. Проверьте TaskManager и при необходимости уничтожьте процессы.
• Откройте окно cmd.exe(это может помочь использовать любые повышенные права, которые вы можете найти), измените путь к окну вашего каталога cygwin/bin (то есть каталог windows cygpath -wa /bin).
• Используйте rebase.exe непосредственно, чтобы найти базовый адрес файла cygwin1.dll:

C:\apps\cygwin\bin> rebase.exe --info cygwin1.dll /usr/bin/cygwin1.dll base 0x61000000 size 0x00500000

5. Используя этот базовый адрес и размер в качестве руководства, я выбрал следующее целое значение как мой базовый адрес базы данных 0x62000000. Нет особых причин для этого, просто догадка. (В rebaseall script используется 0x70000000).
6. Используйте rebase.exe, чтобы исправить все DLL файлы, перечисленные в файле, с шага (1):

C:\apps\cygwin\bin> rebase -b 0x62000000 -4 -n -v -t -T rebasedlls.txt

До сих пор, так хорошо, мой Cygwin снова возвращается в рабочее состояние.

Ответ 4

Вот исправление.

• Перейдите к настройкам Центра защиты Windows Defender
• Нажмите "Управление приложениями и браузерами"
• В нижней части экрана нажмите ссылку "Параметры защиты от использования"
• Перейдите в "Настройки программы" и нажмите "Добавить программу в customize "- > " Выберите точный путь к файлу "
• Перейдите к "C:\Program Files\ Git\usr\bin\sh.exe" и добавьте его
• Отменить и отключить следующее: Обязательный ASLR, Ранжирование памяти в памяти (снизу вверх ASLR)
• Нажмите "Применить", и теперь все должно работать нормально.

Также добавьте эти другие двоичные файлы из одной папки: expr.exe, uname.exe, grep.exe, rm.exe

Удачи,
Габриэль

Ответ 5

Существует утилита rebase, которая запускает rebase как фазу пост-настройки.

Из тире или bash:

/usr/bin/rebase-trigger full

закрыть весь процесс и снова запустить setup-x86_64.exe.

Ответ 6

удалите его, и установите программное обеспечение для 32-разрядной версии.

Ответ 7

Я перезапустил 3 раза, и тогда все было хорошо. Windows 7

Ответ 8

Это точно такое же сообщение об ошибке имеет различные причины, не все они связаны с setup-x86_64.exe, хотя я видел его также и в этом контексте. Но если rebaseall не решил вашу проблему, вот предложение, которое может сработать.

В случае, который я видел сегодня утром, это, как оказалось, было вызвано парой процессов, которые продолжали выполняться после того, как я вышел из эмулятора терминала mintty. Я догадываюсь, что эти зомби-процессы мешают утилизации консоли. В моем случае эти два процесса были определены экспериментально, просмотрев список запущенных процессов для случайных процессов, которые больше не нужны. Я нашел два процесса, которые блокировали меня, просмотрев список запущенных задач.

C:\WINDOWS\system32>tasklist | grep Console

CobraWinLDTP.exe             31844 Console                    1     43,600 K
geckodriver.exe              52640 Console                    1     32,164 K

C:\WINDOWS\system32>taskkill /F /PID 31844
SUCCESS: The process with PID 31844 has been terminated.

C:\WINDOWS\system32>taskkill /F /PID 52640
SUCCESS: The process with PID 52640 has been terminated.

Я видел в некоторых других вопросах о стековом потоке, что git часто является процессом зомби, который вызывает этот симптом (для некоторых пользователей). К сожалению, любой остаточный процесс, который сохраняется после закрытия сеанса консоли, может вызвать эту проблему, поэтому вам придется экспериментировать.