4

I am getting sporadic kernel panics like this:

*** 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)

[…]

(find the rest of the log in this gist)

I’ve read through the Apple tech note on debugging Kernel Panics, but couldn’t find how to apply it to this panic, plus the link to download the Kernel Debug Kit is broken, so I did not manage to get a mapping of kexts in kernel memory – iow, I do not know what was loaded around 0xffffff80189d435f.

I also read through the source code, which “manage[s] the Protocol Control Blocks”, i.e. all the statekeeping for TCP sockets. The function in question is:

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);
  }
}

which suggests to me that the problem is in the network stack and might have something to do with keeping track of buffers, but I’m not enough of a BSD or TCP expert to understand the control flow.

I’m at a loss as to the best way to debug this further – my hunch is that it has to do with the VPN client (Pulse Secure, formerly Junos), but I cannot reliably trigger the crash, it simply happens with time (and when I was observing it, it only happened while on the VPN, but n=2). I need both a virus scanner and Pulse Secure to be able to do my work.

UPDATE The crash just happened again after barely 6 hours of uptime, most of which was spent idle. Ran diagnostics yesterday, got the all ok, booted computer in the morning, put it to sleep for breakfast, rode to the airport, opened it again and it crashed after a few (<2) minutes. I was on VPN when it woke up. Also, because this was a rather “clean” crash, the last loaded kexts were:

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)

as I had not connected any USB devices since the last cold boot, again suggesting to me that it is not a hardware or USB issue, but one with the VPN and/or kernel-side TCP stack.

  • Do the panic reports always show "BSD process name corresponding to current thread: Google Chrome"? – the eels have eyes Sep 13 '17 at 1:18
  • @theeelshaveeyes No, it is always different processes, sometimes kernel_task. The crashes also happened when I went without using Chrome for months. – moeffju Sep 13 '17 at 7:34
  • I am now suspecting HoRNDIS. Tried uninstalling the kext and no crashes since several days. – moeffju Sep 21 '17 at 17:02

You must log in to answer this question.

Browse other questions tagged .