make: Interrupt / Exception catch

33

Używam Make z dystrybucji MinGW. Zawsze działało, ale ostatnio wystąpił następujący błąd:

> make clean
make: Interrupt/Exception caught (code = 0xc0000005, addr = 0x0040b0ac)

Odpowiednia część wygląda następująco:

clean:
    del /S /Q *.o > nul
    del /S /Q *.cy.c > nul
    del /S /Q *.pyc > nul
    del /S /Q *.pyo > nul
    if EXIST build (rmdir /S /Q dist > nul)

Nie mam pojęcia, co to powoduje. Zwłaszcza, że ​​zawsze działało idealnie dobrze.

windows make mingw orlp
źródło
1
Czy próbowałeś zaktualizować markę? gnu.org/software/make
Fabián Heredia Montiel

Odpowiedzi:

46

Zaczynałem też otrzymywać wyjątek:

make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4227d3)

Może być inny powód, ale ten problem jest spowodowany najwyraźniej, gdy zmienna PATH zawiera nawiasy (, )jak ma to miejsce na Win Vista / 7. Niestety dostępne GNU dla Windows jest beznadziejnie przestarzałe.

Mój problem został rozwiązany przez wymuszenie makeużycia poprawnej powłoki: wstaw następujący wiersz na początku pliku makefile.

SHELL=C:/Windows/System32/cmd.exe
Norbert P.
źródło
Świetne rozwiązanie, ale nie wiem, dlaczego nie działało, nie mam nawiasów w moich zmiennych środowiskowych
forsubhi
1
Czy może być również związany z długością ŚCIEŻKI? W moim przypadku moja ŚCIEŻKA miała już wiele nawiasów bez żadnych problemów (dopóki nie zainstalowałem więcej rzeczy); zastąpienie wszystkich wystąpień C:\Program Filesze C:\PROGRA~1i C:\Program Files (x86)ze C:\PROGRA~2stałym problemem dla mnie. +1 :-)
Cameron
Ja także miałem ten problem, i włączony do nowszej wersji Marka: equation.com/servlet/equation.cmd?fa=make - To nie rozwiąże problemu, ale obsługuje on wyjątek lepiej i mówi, co się dzieje: sh: C:\Program: No such file or directoryjest pierwszy wiersz, który otrzymuję, jeśli nie podam SHELLzmiennej. Zasadniczo każde wystąpienie „Program Files” na PATH zawiera spację, która nie jest poprawnie usuwana (jeśli chodzi o markę). To nie długość ścieżki, ale spacje powodują ten problem. To wyjaśnia, dlaczego użycie makra bez spacji to naprawiło.
Johannes
To rozwiązanie działało dla mnie.
Robert Stiffler,
8

Miałem ten problem, gdy dodałem katalog bin Gita do PATHzmiennej środowiskowej. Wydaje się, że powodem jest to, że Git jest dostarczany z wersją MSYS i wydaje się, że jest w konflikcie z MinGW (może nie jest to sprzeczne, gdy jest to odpowiednia wersja MSYS i / lub MinGW, ale to tylko zgadywanie).

Upewnij się więc, że nie ma (innej) dystrybucji MSYS w twoim PATH.

Zapłonnik
źródło
1
Problemem była ścieżka Git do katalogu bin! Dobra robota !
TridenT
3

Później do odpowiedzi Norbet P. stwierdziłem, że dodanie:

PATH=

na górze mojego pliku Makefile naprawiłem ten konkretny problem.

Mark Tolley
źródło
1
Nie daję -1, ale to jest strasznie zła odpowiedź. Nie możesz po prostu zresetować ŚCIEŻKI !!! to bardzo zła praktyka! czasami kompilacja programu zależy od informacji w PATH.
The Quantum Physicist,
3

Ten makebłąd został naprawiony co najmniej w

GNU Make 3.82
Built for i686-pc-mingw32

.

Armali
źródło
Skąd mogę wziąć tę wersję?
SHOUBHIK BOSE
1
IIRC, mam to stąd .
Armali
2

Używałem GnuWin, dopóki nie zdałem sobie sprawy, że ostatnie wydanie zostało opublikowane 26 listopada 2006 roku . To trochę kiepskie i spowodowało takie problemy, jak widać powyżej. Ustawienie SHELL = C: /Windows/System32/cmd.exe rozwiązuje niektóre problemy, ale uruchomienie takiego starego kodu w nowych systemach operacyjnych wydaje się niebezpieczne

MinGw to bezpieczniejszy zakład. MinGw jest akronimem „Minimalistyczny GNU dla Windows” i jest aktualny i obejmuje markę oraz inne narzędzia

http://sourceforge.net/projects/mingw/files/

użytkownik246954
źródło
1
Czy w ogóle przeczytałeś pytanie?
orlp
1

Kod błędu systemu Windows 0xC0000005wskazuje na naruszenie dostępu lub błąd segmentacji.

  • Czy Twoja instalacja MinGW jest uszkodzona?
  • Czy Twój system jest poprawnie skonfigurowany? Czy ostatnio zmieniły się jakieś ustawienia systemu?
  • Czy w twoim systemie występują problemy sprzętowe? Może być konieczne przeskanowanie dysku twardego za pomocą CHKDSK lub wykonanie testu pamięci, takiego jak Memtest86 + .
bwDraco
źródło
-1

Zauważyłem w moich dziennikach kompilacji, że „SHELL = sh” było przekazywane, mimo że jestem na platformie Windows. Mój Makfile wyglądał tak:

ifneq (, $ (findstring win, $ (RDI_PLATFORM))) SHELL = CMD endif

Raz skomentowałem ifneq i koniec, że zaczął działać. Nie jestem pewien, dlaczego platforma nie została poprawnie zinterpretowana.

martinv
źródło
1
To nie jest odpowiedź na pierwotne pytanie. Aby skrytykować lub poprosić autora o wyjaśnienie, zostaw komentarz pod jego postem - zawsze możesz komentować własne posty, a gdy będziesz mieć wystarczającą reputację , będziesz mógł komentować każdy post .
DavidPostill