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

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