Jak debugować błędy w wartownikach i podczas blokowania czcionek


10

Kiedy wystąpi błąd wewnątrz wartownika procesu lub podczas blokowania czcionek, Emacs nie pokazuje śladu wstecznego, mimo że debug-on-errorwcześniej był włączony.

Rozumiem, dlaczego te błędy są wychwytywane, ten sam błąd może zostać ponownie uruchomiony podczas próby przedstawienia śledzenia wstecznego. Jednak gdy chcę naprawdę debugować ten błąd, nie jest to bardzo pomocne. Wolę ryzykować, że Emacs przestanie odpowiadać, niż będę musiał z tego pracować:

error in process sentinel: Wrong type argument: stringp, nil

W końcu mogę po prostu rozpocząć drugą instancję, jeśli pierwsza zacznie wariować. Nieco większy kontekst pomógłby, gdy istnieje wiele miejsc, w których teoretycznie taki błąd mógłby teoretycznie wystąpić w wartowniku.

Jak więc zmusić Emacsa do pokazania debug-on-errorśladu wstecz, nawet w przypadkach, gdy nie ma to żadnego efektu?


1
Widziałem emacs.stackexchange.com/questions/3552/…, ale myślę, że powinno być ogólne pytanie na ten temat, a nie tylko jeden konkretny przypadek. Mam też nadzieję, że „użyj printf” nie jest jedyną odpowiedzią, ponieważ tego właśnie użyłem w przeszłości i nie jest to satysfakcjonujące, zwłaszcza jeśli błąd brzmi „Nieprawidłowe odniesienie do twarzy: some-face-which-i-absolutnie wiem -exists ”, które może zostać uruchomione przez prawie każdy pakiet, który zainstalowałem.
Tarsius

Adres URL wskazuje na to pytanie i dlatego jest raczej mylący w twoim komentarzu, czy jest to celowe czy błąd w Twoim imieniu?
wasamasa

To właśnie miałem na myśli: ttp: //emacs.stackexchange.com/questions/1045/how-to-debug-startup-problem-if-debug-init-has-no-effect
tarsius

link zamierzony przez tarsius: emacs.stackexchange.com/questions/1045/… ‌ ug-init-has-no-effect
dcorking

Odpowiedzi:


10

Jeśli chodzi o wartowników procesowych, nie sądzę, żeby był to dobry powód. IOW Myślę, że to po prostu brakująca funkcja, więc sugeruję M-x report-emacs-bug.

W przypadku blokowania czcionek problem jest trudniejszy, ponieważ tak naprawdę dzieje się tak, że błąd jest wyzwalany podczas blokowania jit, tj. Podczas ponownego wyświetlania, i nie możemy łatwo wejść do debuggera w tym momencie (IIRC w pewnym momencie Gerd próbował zrobić działa, ale nadal były poważne problemy). Możesz więc debugować go na jeden z następujących sposobów:

  • M-x jit-lock-debug-mode która zmienia blokadę jit, aby działała zaraz po ponownym wyświetleniu, abyśmy mogli wejść do debuggera.
  • M-: (setq font-lock-support-mode nil) RETa następnie wyłącz + włącz ponownie blokadę czcionek. W ten sposób font-lock nie używa jit-locka, więc działa podczas polecenia użytkownika, a nie podczas kolejnego ponownego wyświetlania.

Właściwie debug-on-errorwydaje się , że działa dobrze na procesorach.
Stefan

@tarsius - proszę zamieścić link do swojego problemu z debbugs
dcorking

Żądanie funkcji Tarsiusa to 19432, gdzie jest oznaczone jako niereprodukowalne. Stefan Monnier opublikował obejście, które wykorzystuje, --evala nie --debug-init . Również jego obejście nie pomaga mi wrócić do .emacs.d
śladu

1
@orkorking: nie, w błędzie # 19432 nie opublikowałem „obejścia”, ale nieudana próba odtworzenia jego błędu. Dlaczego nie wyślesz przepisu, aby odtworzyć swój problem?
Stefan
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.