Czy losowe sygnały SIGTRAP (w trybie MinGW-gdb) są oznaką uszkodzenia pamięci?

Question

Napisałem swój własny odnośnik do licznika pamięci C++ (dla zabawy) i jestem pewien, że nie jest idealny;). A teraz, kiedy próbuję go użyć, otrzymałem losowe sygnały SIGTRAP. Jeśli skomentuję każdą linię związaną z tym menedżerem pamięci, wszystko działa poprawnie. Uzyskanie SIGTRAP-ów zamiast SIGSEGV jest dość dziwne. Wiem, że SIGTRAP-y są generowane, gdy program osiągnie punkt przerwania, ale nie ustawiono punktu przerwania. Czytałem w innym wątku, że debugowania kompilacji exe i biblioteki DLL muszą być aktualne. Są aktualne i nie jest to powód.

Czy ktoś wie, dlaczego tak się dzieje?

Answer 1

Po przeprowadzeniu wyszukiwania w Google zdałem sobie sprawę, że te sigtraps są takie same jak te ostrzeżenia otrzymane w MSVC++, mówiąc "Windows uruchomił punkt przerwania w xxxx.exe. Może to być spowodowane uszkodzeniem sterty i wskazuje błąd blahblahblah ”...

wydaje się więc tak, nieoczekiwane sigtraps może wskazywać corrupction pamięci (dość dziwne ...)

I znalazłem mój błąd, zbyt. MM znajduje się w statycznej bibliotece, która jest połączona z biblioteką dll. I to statyczne lib i biblioteka dll jest połączona z moim exe. Więc było dwóch menedżerów pamięci, jeden w moim exe i jeden w mojej bibliotece dll. Jeśli wywołujemy metodę initaializacji MM. Zainicjował MM w moim exe, ale nie w bibliotece dll, więc biblioteka DLL przeszła bez init. Rozwiązałem to, nie łącząc mojego exe z tą statyczną biblioteką.

Answer 2

Zgaduję, że możesz wywoływać niedopasowane nowe/usuwać lub usuwać implementacje za darmo - Więc coś zostało przydzielone przez twojego menedżera pamięci, ale kiedy pamięć zostanie zwolniona, skończysz z domyślną implementacją delete/free .

Ustaw punkt przerwania sygnału i sprawdź, czy na stosie jest wolne() lub usuń operator i czy jest to implementacja wspomnianej funkcji, jakiej można się spodziewać.