macOS 10.12.6: Panika, asercja nie powiodła się: ifp-> if_sndbyte_total> = len, bsd / netinet / in_pcb.c, linia: 3458

Sporadycznie wpadam w panikę jądra:

*** Panic Report ***
panic(cpu 3 caller 0xffffff80189d435f): assertion failed: ifp->if_sndbyte_total >= len, file: /Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.70.16/bsd/netinet/in_pcb.c, line: 3458

[…]

Mac OS version:
16G29

Kernel version:
Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64
Kernel UUID: [REDACTED]
Kernel slide:     0x0000000018200000
Kernel text base: 0xffffff8018400000
__HIB  text base: 0xffffff8018300000
System model name: MacBookPro12,1 (Mac-[REDACTED])

System uptime in nanoseconds: 205886295907546
last loaded kext at 205508810738561: com.apple.driver.usb.cdc   5.0.0 (addr 0xffffff7f9b612000, size 28672)
last unloaded kext at 196312576713453: com.apple.driver.usb.AppleUSBHostCompositeDevice 1.1 (addr 0xffffff7f9b60b000, size 28672)

[…]

( znajdź resztę dziennika w tej liście )

Przeczytałem notatkę techniczną Apple dotyczącą debugowania Kernel Panics , ale nie mogłem znaleźć sposobu, aby zastosować ją do tej paniki, a ponadto link do pobrania zestawu do debugowania jądra jest uszkodzony, więc nie udało mi się uzyskać mapowania kextów w pamięci jądra - no, nie wiem, co zostało załadowane 0xffffff80189d435f.

Przeczytałem również kod źródłowy , który „zarządza [s] blokami kontroli protokołu”, tj. Wszystkimi statkami dla gniazd TCP. Ta funkcja to:

inline void
inp_incr_sndbytes_unsent(struct socket *so, int32_t len)
{
  struct inpcb *inp = (struct inpcb *)so->so_pcb;
  struct ifnet *ifp = inp->inp_last_outifp;

  if (ifp != NULL) {
    VERIFY(ifp->if_sndbyte_unsent >= 0);
    OSAddAtomic64(len, &ifp->if_sndbyte_unsent);
  }
}

co sugeruje mi, że problem dotyczy stosu sieciowego i może mieć coś wspólnego z śledzeniem buforów, ale nie jestem wystarczająco ekspertem od BSD lub TCP, aby zrozumieć przepływ sterowania.

Brakuje mi najlepszego sposobu dalszego debugowania - moje przeczucie polega na tym, że ma to związek z klientem VPN (Pulse Secure, dawniej Junos), ale nie mogę niezawodnie wywołać awarii, po prostu dzieje się to z czasem ( a kiedy to obserwowałem, zdarzyło się to tylko w sieci VPN, ale n = 2). Potrzebuję zarówno skanera antywirusowego, jak i Pulse Secure, aby móc wykonywać swoją pracę.

AKTUALIZACJA Awaria zdarzyła się ponownie po zaledwie 6 godzinach bezczynności, z których większość była bezczynna. Wczoraj przeprowadziłem diagnostykę, wszystko w porządku, rano uruchomiłem komputer, położyłem go spać na śniadanie, pojechałem na lotnisko, otworzyłem go ponownie i rozbił się po kilku (<2) minutach. Byłem na VPN, kiedy się obudził. Ponadto, ponieważ była to raczej „czysta” awaria, ostatnio załadowane kexts to:

last loaded kext at 1743857437016: com.apple.driver.usb.cdc 5.0.0 (addr 0xffffff7f94191000, size 28672)
last unloaded kext at 898332773796: com.apple.driver.AppleIntelLpssI2C  3.0.60 (addr 0xffffff7f93853000, size 40960)

ponieważ od ostatniego zimnego rozruchu nie podłączyłem żadnych urządzeń USB, ponownie sugerując mi, że nie jest to problem sprzętowy ani USB, ale jeden ze stosem VPN i / lub stosem TCP po stronie jądra.