Szalony czas spędzony na hakach z free/malloc, pamięci zewnętrznej?

Question

To jest częściowo związane z programowaniem/debugowaniem, częściowo z zewnętrznym systemem operacyjnym (kandydat SuperUser?), Ale mimo to opublikowałem go tutaj, ponieważ jeśli ktokolwiek powinien znać odpowiedź, to jest tutaj.

Opracowywałem program, gdy nagle nowa kompilacja (bez większych zmian) spowodowała, że ​​wszystko się zatrzymało. Profilowałem to, aby zobaczyć, co zajęło, ale rozkład% był normalny - wszystko, co, zajęło mi znacznie więcej czasu.

Szlifowanie przez sterty z Very Sleepy, zauważyłem, że free/malloc/delete/realloc stanowi 95% + środowiska wykonawczego. Podejrzewając uszkodzenie sterty, wycofałem wszystkie zmiany, ale nic się nie zmieniło.

Używając profilera MSVC, odkopałem stos wywołań poza malloc/realloc i zakończyłem - o dziwo - w zewnętrznej bibliotece dll o nazwie Acxtrnal.dll. Oto klip stosu: http://i.imgur.com/0xXv5MV.png

Najwyraźniej niektóre zewnętrzne biblioteki dll są podpięte do procedur sprawdzania poprawności sterty w moim programie. To mnie lekko niepokoi. Googling dll ujawnia tylko jedno oficjalne źródło informacji (coś o trybie kompilacji, nie dotyczy): https://support.microsoft.com/en-us/kb/2272691

Po spędzeniu pół dnia na debugowaniu z niedowierzaniem, problem zniknął. Wygląda na to, że ten facet miał ten sam problem, chociaż "odpowiedź" prawdopodobnie nie ma związku: When profiling my fortran program, Acxtrnal.dll is the part using most of the CPU time! What is that dll.?

Teraz jestem zarówno ciekawy, jak i zaniepokojony; czy powróci - i dlaczego stało się tak w pierwszym przypadku? Byłbym wdzięczny, gdyby ktoś doświadczył czegoś podobnego, abyśmy mogli rzucić światło na tę kwestię. Chociaż ten problem wydaje się rzadki, może to pomoże komuś tam.

Answer 1

Dzięki za zbiorową pomoc. Na przyszłość (i Googlersi):

Problem jest spowodowany przez Windows odporne na uszkodzenia Heap: https://msdn.microsoft.com/en-us/library/windows/desktop/dd744764(v=vs.85).aspx

Jest to usługa proces specyficzny instancja kiedy uda Ci się uszkodzony sterty do jakiegoś nieznanego stopnia. Nie wiadomo, jak dokładnie wyłączyć usługę ponownie; niektórzy mówią, zmień nazwę pliku DLL api (znalezionego w \ windows \ apppatch \ acxtrnal.dll) lub wyłącz go poprzez rejestr.

W moim przypadku mój program był plugin-dll, a podobno rozwiązałem problem z hostem biblioteki dll w innym programie.

Więcej informacji można znaleźć w komentarzach, a tu: http://billroper.livejournal.com/960122.html

How do I turn off the fault tolerant heap?