Skype Crash OS X

For the last few months Skype has been crashing every time I tried to start it on my MacBook Pro. There were error messages in the crash log like this

Thread 0 Crashed:
0   <<00000000>>        0xffff07d7 __memcpy + 55 (cpu_capabilities.h:228)
1   ...ickTimeComponents.component      0x991fa700 _SGVideoGetChannelDeviceList + 2069
2   ...ple.CoreServices.CarbonCore      0x90cd0a53 CallComponentFunctionCommon + 513
3   ...ickTimeComponents.component      0x991edb29 _SGVideoComponentDispatch + 123
4   ...ple.CoreServices.CarbonCore      0x90cd0738 CallComponentDispatch + 34

Which led me to think it was something to do with Quicktime and/or video. So it occurred to me that starting iChat and opening the video preview before starting skype might help. It does!

libpcap on OS X

Earlier I wrote about a problem with libpcap on OS X. This is the call in the code that breaks the wireless connection.

/* ask pcap to find a valid device for use to sniff on */
dev = pcap_lookupdev(errbuf);

but replace it with this (en1 is my wireless interface)


and then use dev in other libpcap functions and it works fine.


One of the tv cards in my mythtv backend requires the driver to load firmware at boot time. The driver for this card was crashing repeatedly so I have been keeping an eye out for updates. The firmware received an upgrade a few months ago but it was still crashing and it was weeks before I realized that the old firmware was still being loaded. It turns out that you have to actually remove the power from the system before it will reload the firmware. A reboot is not sufficient. This really needs to be in BIG letters somewhere on the linuxtv site.

Anyway I now have a whole month of uptime on the backend. This is only the second time I have had the system so stable in the 3-4 years I have been running mythtv.

libpcap on OSX

The other day I was playing with libpcap on my MacBook Pro. Every time I tried to run the code my wireless network connection was disconnected.

After a bit of playing around I also found this was happening with tcpdump. It appears that running tcpdump -i en1 where en1 is the wireless network interface works fine. I guess the problem is something to do with the call to scan for interfaces.