Closed GoogleCodeExporter closed 9 years ago
What makes you think this was caused by Tunnelblick?
The log indicates that Tunnelblick last had a VPN connection at 2012-07-17
19:39:26.
The crash did not occur until 22:03:03, over two hours later.
Original comment by jkbull...@gmail.com
on 27 Jul 2012 at 4:01
i did not terminate the vpn connection before the crash, i simply did not use
it between 19:39 and the crash ..
why do i think tunnelblick is involved in it:
first of all, the repeated system crashes only occur when i was using
tunnelblick vpn.
also, i might be a naive reader of the crash log but the following facts
supported my guess that tunnelblick was involved in it:
- current task : 'BSD process name corresponding to current thread: kernel_task'
- loaded kexts:
System uptime in nanoseconds: 28796566511890
unloaded kexts:
net.tunnelblick.tun 1.0 - last unloaded 26473754239116
loaded kexts:
net.tunnelblick.tun 1.0
tunnelblick is mentioned here twice at the beginning ..
i'm no pro in reading these crash logs. am i completely off?
Original comment by michigra...@gmail.com
on 28 Jul 2012 at 10:41
No, you're not completely off. (I'm not a pro at reading the crash logs
either.) But the line
- current task : 'BSD process name corresponding to current thread: kernel_task'
is just saying that the OS X kernel was what crashed. That doesn't really mean
much, although a couple of years ago when there was a bug in the Tunnelblick
kext (kernel extension = device driver for the VPN), the current task in crash
reports was more clearly related to networking.
However, the two logs appear to disagree about whether or not the VPN was
connected at the time of the crash:
From the Tunnelblick log, the VPN connection was terminated beginning at
19:39:25. Termination was finished at 19:39:26.
From the crash dump, the Tunnelblick kext was loaded at the time of the crash
-- 22:03:03.
These are contradictory because ordinarily the Tunnelblick kext is loaded only
when a VPN connection is active (being made, connected, or disconnecting). When
a VPN connection is closed down, the kext is usually unloaded. However, there
are circumstances that cause Tunnelblick to leave the kext loaded, and that may
be the explanation here.
That's not to say that Tunnelblick wasn't involved. It's just that Tunnelblick
(if there was no VPN connection) did not have any "root" processes running at
the time of the crash. The only thing running was the Tunnelblick application
itself, which runs at the normal user level (like Safari or iCal).
This is the first report of a kernel panic (system crash) in almost a year,
since a bug in the kexts that happened only on OS X 10.7, and only affected
certain CPUs) was fixed. And I don't remember ever seeing a kernel panic on OS
X 10.5.
So there may be something else going on here. Either a problem with your OS X
installation, or some other program is causing the panic. You have other
non-Apple kexts loaded from Cisco, Sophos, and National Instrument. Maybe one
of those is causing the problem, or maybe they cause a problem only when a
Tunnelblick kext is loaded. (Or, maybe it _is_ the Tunnelblick kext that's
causing the problem.)
I'm sorry you're having these crashes, but there isn't much that I can do about
it. There isn't enough in the crash dumps to show what's really going on.
Original comment by jkbull...@gmail.com
on 28 Jul 2012 at 11:25
Original comment by jkbull...@gmail.com
on 1 Aug 2012 at 5:03
Original issue reported on code.google.com by
michigra...@gmail.com
on 17 Jul 2012 at 9:30