kernel panic everytime I use ping
 

I'm having kernel panics everytime I use the ping command. From Termninal.app ie:

>Ping www.google.com
kernel panic

I have tried the following:
-Repair Permissions
-Repair Disk (Disk Utility)
-Rebuild Directory Structure (Disk Warrior)

-I have also logged in as another user and tried it and it worked.
-So I logged back in as the original user then deleted com.apple.Terminal.plist, but it still crashed.
-I tried running ping from the X11.app and it worked.
-I tried running from something besides bash:
>sh
>ping www.google.com
kernel panic

From both the X11 terminal and Terminal.app
>which ping
/sbin/ping

So, to sum it all up, it doesn't seem to be the ping command b/c it works for different users in Terminal.app and under my normal user under X11.app. Likewise it is shell agnostic. I'm out of ideas and would appreciate any help. Is there a way to uninstall every trace of terminal.app and get a fresh copy?
Thanks in advance...
-Willy

I think you need to clear about the issue you are experiencing.

Kernel panics = General system failure requiring a restart
Application crash = Application unexpected quit.

It is not clear from your post which of the above you are experiencing.

I agree with bramley
It would be better if you told us exactly what is happening (what you see, the exact text of any error messages, etc) instead of interpreting.

Also please show us the complete crash report and other error messages from system.log and console.log.
Launch the "Console" application (under /Applications/Utilities) and look for relevant error messages. Note that messages are labeled with the date & time so you can use that to locate the part of the log to look at. Copy & paste the relevant messages back here so we can see them.
Be sure to look at system.log as well as console.log (Use the "Logs" button (top-left) to see the various logs available - note that you will probably need to be an "admin" user to see the system.log)

If the log refers to a crash log, press the "Logs" button (top-left) and go into the ~/Library/Logs section to find that particular crash log. Copy & paste back here the last portion of that crash log - the part that gives details about the last crash (or preferably attach it as a plain text file, using the "Manage Attachments" button at the bottom when you reply).

If (unlikely as this seems to me) it really is a kernel panic that you are experiencing, then please show us the contents of the file "panic.log" that is under /Library/Logs

Also please tell us what model of Mac you have and what version of OS X you are running.

Note also that 'sh' and 'bash' are not really different shells - they in fact run the exact same executable. There are only small differences in what startup files they read.

The fact that it works from an xterm would seem to indicate that the problem is related to something in your shell startup files since a shell in xterm is a non-login shell and hence reads different "dot" files than one in Terminal.
See this Unix FAQ for details.

You may want to check out iterm.sf.net to further narrow down you extremely weird problem.

Does it just print "kernel panic" or do you need to reboot the machine ?

Do you have aliased ping to something else or otherwise interfered with the standard installation ?

The md5 hash for 10.4.7 PPC is:

md5 /sbin/ping

MD5 (/sbin/ping) = 3d0584bc2fd38c4134cf0a1e80c65a60

Does that check out ok for you ?

Hmmmm. That's not the md5 I get with 10.4.7 PPC:

Trevor

Mine agrees with voldenuit's:

Curious. I have a different date on my ping executable:
Perhaps you've installed Security Update 2006-004 and I haven't?

Trevor

Thank you all for your help, I'm going to take this one at a time:

-machine and version are in my sig. Latest means latest. So my checksum matches up w/ those who have done the latest security update:
-md5 /sbin/ping
MD5 (/sbin/ping) = 3d0584bc2fd38c4134cf0a1e80c65a60

-I wrote that post badly and implied that things were crashing and panicing. Just to be clear, the ONLY problem I'm having is a kernel panic when I ping from terminal.app.
-I have always understood a kernel panic to be when the screen goes dark and it tells you to reset the machine by pushing the start button in 12 languages. I've also appended a panic.log at the end of this post.

-I thought that by switching from bash to sh I would not read ~/.profile. When I did that test I was trying to test my .profile.
-I'm not sure why, but re-naming my .profile fixed it.
-I still don't understand why switching shells still caused a panic.
-I didn't know that bash and sh are equivalent executables. I just diff'd them and sure enough it's two copies of the same thing.
-But, sh doesn't read my .profile (I always have an echo in there to make sure.)
-Finally here's my .profile, the culprit of all the panics. Any ideas what's wrong w/it?
-It's worked fine for ages, but this is the first time I've used it since I did the security update, and thus the first time I've used it w/ our new ping.
++++++++++++.profile++++++++++++++++++++
#QT stuff
QTDIR=/Developer/qt
DYLD_LIBRARY_PATH=$QTDIR/lib:$DYLD_LIBRARY_PATH
PATH=$QTDIR/bin:$PATH
PATH=.:$PATH:/usr/local/Trolltech/Qt-4.0.1/bin
QMAKESPEC=macx-pbuilder
export QTDIR PATH DYLD_LIBRARY_PATH

#Open Scene Graph Stuff
OPENTHREADS_INC_DIR=/usr/local/OpenSceneGraph/OpenThreads/include/
OPENTHREADS_LIB_DIR=/usr/local/OpenSceneGraph/OpenThreads/lib
PRODUCER_INC_DIR=/usr/local/OpenSceneGraph/Producer/include
PRODUCER_LIB_DIR=/usr/local/OpenSceneGraph/Producer/lib

alias ff='find . -name'
alias ls='ls -G -l -F'
PS1="[\\h:\\W] \\u\\$ "

echo profile read

++++++++++++++++end .profile+++++++++++++++++

++++++++++++++++panic log+++++++++++++++++++

Wed Aug 30 00:42:36 2006


Unresolved kernel trap(cpu 0): 0x300 - Data access DAR=0x0000000000000010 PC=0x00000000009A12C4
Latest crash info for cpu 0:
Exception state (sv=0x215A4500)
PC=0x009A12C4; MSR=0x00009030; DAR=0x00000010; DSISR=0x40000000; LR=0x009A128C; R1=0x0D043720; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x009A128C 0x009A1C98 0x009A336C 0x009A3E9C 0x00291050 0x00296348
0x0029651C 0x002AAF98 0x000ABF30 0x0197C1E0
Kernel loadable modules in backtrace (with dependencies):
at.obdev.KUC(1.2.47)@0x99d000
Proceeding back via exception chain:
Exception state (sv=0x215A4500)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x2FB48C80)
PC=0x900204C0; MSR=0x0000F030; DAR=0x0001A000; DSISR=0x42000000; LR=0x00004538; R1=0xBFFEF710; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.7.0: Fri May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC
panic(cpu 0 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 0:
Backtrace:
0x00095718 0x00095C30 0x0002683C 0x000A8404 0x000ABD80
Proceeding back via exception chain:
Exception state (sv=0x215A4500)
PC=0x009A12C4; MSR=0x00009030; DAR=0x00000010; DSISR=0x40000000; LR=0x009A128C; R1=0x0D043720; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x009A128C 0x009A1C98 0x009A336C 0x009A3E9C 0x00291050 0x00296348
0x0029651C 0x002AAF98 0x000ABF30 0x0197C1E0
Kernel loadable modules in backtrace (with dependencies):
at.obdev.KUC(1.2.47)@0x99d000
Exception state (sv=0x2FB48C80)
PC=0x900204C0; MSR=0x0000F030; DAR=0x0001A000; DSISR=0x42000000; LR=0x00004538; R1=0xBFFEF710; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.7.0: Fri May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC

Thank you all very much for your thoughts.

Yes - I have installed Security Update 2006-004
But that update didn't change /sbin/ping
Perhaps the prebinding on /sbin/ping got changed after that update?
But 'otool -L /sbin/ping' shows that it only depends on /usr/lib/libSystem.B.dylib
and that wasn't changed in the security update.

Maybe you should just apply the security update and see if that changes the md5 hash of /sbin/ping

Please review the "shell startup files" section of this Unix FAQ for details on what "dot" files are read by the various shells. I think that will clear up the mystery for you.

I don't see what is wrong with it. It's probably something to do with the PATH or DYLD_LIBRARY_PATH modifications.
Are you sure that you are running /sbin/ping (as opposed to some other version)?

The fact that the panic.log says that "at.obdev.KUC" is in memory at the time of the crash likely indicates that the problem is related to a kernel extension installed by the company "Objective Development" ( http://obdev.at/ ) - they make Little Snitch among other things.

For what it's worth, setting a DYLD_LIBRARY_PATH in one's global shell env tends to lead to all manner of runtime problems. Much safer to localize it in a wrapper script around the specific program that needs it. And much safer to use DYLD_FALLBACK_LIBRARY_PATH instead (i.e., check these paths after failing to find a lib in the normal place instead of overriding and looking there before in the normal place). Darwin's DYLD_* variables are unlike those on linux (see the dyld manpage for more info).

Also, is that variable already set, or is your .profile the first time it gets defined? If you DYLD_LIBRARY_PATH=$QTDIR/lib:$DYLD_LIBRARY_PATH when it is not previously defined, you get a null path element instead of "the default search path", which seems like it might give unpredicable results.

Good to hear we probably nailed the culprit.

Note that the most recent version of LS is 1.2.3 has a more recent kext:

101 0 0xb9b000 0x16000 0x15000 at.obdev.KUC (1.2.61) <6 5 4 3 2>

It's unexpected that ping would change it's md5 hash before and after the latest SecUpdate (which I did indeed install), here's the list of the BOM, generated with hayne's clever script:

pkgsummary.sh /Library/Receipts/SecUpd2006-004Ti.pkg
.
./System
./System/Library
./System/Library/CoreServices
./System/Library/CoreServices/AppleFileServer.app
./System/Library/CoreServices/Bluetooth Setup Assistant.app
./System/Library/Frameworks
./System/Library/Frameworks/ApplicationServices.framework
./System/Library/Frameworks/WebKit.framework
./System/Library/PrivateFrameworks
./System/Library/PrivateFrameworks/Bom.framework
./System/Library/PrivateFrameworks/DiskManagement.framework
./private
./private/var
./private/var/db
./private/var/db/dyld
./private/var/db/dyld/update-prebinding-paths.txt
./usr
./usr/bin
./usr/bin/fetchmail
./usr/bin/gunzip
./usr/bin/gzcat
./usr/bin/gzip
./usr/bin/scp
./usr/bin/sftp
./usr/bin/ssh
./usr/bin/ssh-add
./usr/bin/ssh-agent
./usr/bin/ssh-keygen
./usr/bin/ssh-keyscan
./usr/bin/telnet
./usr/bin/zcat
./usr/bin/zegrep
./usr/bin/zfgrep
./usr/bin/zgrep
./usr/lib
./usr/lib/dyld
./usr/lib/pam
./usr/lib/pam/pam_afpmount.so
./usr/libexec
./usr/libexec/bootpd
./usr/libexec/sftp-server
./usr/libexec/ssh-keysign
./usr/sbin
./usr/sbin/sshd
./usr/share
./usr/share/man
./usr/share/man/man1
./usr/share/man/man1/fetchmail.1
./usr/share/man/man1/telnet.1
.
./System
./System/Library
./System/Library/CoreServices
./System/Library/CoreServices/AppleFileServer.app
./System/Library/CoreServices/Bluetooth Setup Assistant.app
./System/Library/Frameworks
./System/Library/Frameworks/ApplicationServices.framework
./System/Library/Frameworks/WebKit.framework
./System/Library/PrivateFrameworks
./System/Library/PrivateFrameworks/Bom.framework
./System/Library/PrivateFrameworks/DiskManagement.framework
./private
./private/var
./private/var/db
./private/var/db/dyld
./private/var/db/dyld/update-prebinding-paths.txt
./usr
./usr/bin
./usr/bin/fetchmail
./usr/bin/gunzip
./usr/bin/gzcat
./usr/bin/gzip
./usr/bin/scp
./usr/bin/sftp
./usr/bin/ssh
./usr/bin/ssh-add
./usr/bin/ssh-agent
./usr/bin/ssh-keygen
./usr/bin/ssh-keyscan
./usr/bin/telnet
./usr/bin/zcat
./usr/bin/zegrep
./usr/bin/zfgrep
./usr/bin/zgrep
./usr/lib
./usr/lib/dyld
./usr/lib/pam
./usr/lib/pam/pam_afpmount.so
./usr/libexec
./usr/libexec/bootpd
./usr/libexec/sftp-server
./usr/libexec/ssh-keysign
./usr/sbin
./usr/sbin/sshd
./usr/share
./usr/share/man
./usr/share/man/man1
./usr/share/man/man1/fetchmail.1
./usr/share/man/man1/telnet.1

It would be interesting to cmp the two ping versions to see what gets changed, it must be more than just the time stamp (that's metadata and doesn't affect the md5). I don't quite understand how that can happen without a new ping binary being listed in the BOM - anybody with a rational explanation for that mystery ?

The only explanation I can think of is that prebinding has changed the executable. But as I said above, I don't see why that would have happened in this case since 'ping' doesn't seem to depend on any dynamic libs that have changed.
If trevor (or anyone else) wants to do a 'cmp' of the 'ping' executables, I attach a zipped version of my /sbin/ping

You may want to get the improved version of that script (from the thread: http://forums.macosxhints.com/showthread.php?p=318221) - I added in a 'sort | uniq' to get rid of the duplicate entries and a 'sed' to get rid of the extraneous dots at the start of lines.

-I just updated to the latest little snitch and everything worked w/ the original .profile.
-when i type:
% which ping
/sbin/ping
-So I have to be using the same ping you guys are right?
-Thanks for the advice about DYLD.

Thanks everyone I never would have gotten that on my own...
-Willy

Attached is the results of
If you prefer other options for cmp let me know.

I've now installed the Security Update, but the md5 checksum and modified date for ping have not changed.

Trevor

It's interesting that the changes seem to be distributed throughout the length of the executable.

Curiouser and curiouser

trevor:
What do you get from 'strings /sbin/ping | grep PROGRAM' ?

Trevor

Very weird indeed, so it seems it isn't the SecUpdate, but something else that makes you end up with different ping versions on otherwise identical OS revisions.

I tend to use full rather than delta system updater, perhaps that could make a difference ? It's really disturbing to know that systems that should be identical when looking at the overall build info really aren't when you look at the binaries installed.

We did know that whether or not cron was present on a Tiger system depended on whether or not it was upgraded from Panther, but what we stumbled upon here is really strange.

Could backtracking ping in Darwin help to understand what's going on here ?

My system is newly rebuilt (after a hard drive crash), so is the result of a "combo" update (from Software Update)
But the version of 'ping' that I have seems to be from the BaseSystem.pkg that was on the Tiger DVD:
Here's my 'grep_pkg' script:

Thanks for the very handy grep_pkg script, I didn't find any other occurrences of ping neither, even when searching just for /ping . How did you manage to get this receipt on a fresh Tiger install:

/Library/Receipts/MacOSX10.3.9.pkg ?

Now we all look Trevors way to find out how he managed to end up with a more recent version of ping on his system.
Compiled you own ping from a patched Darwin source, then forgot about it ;) ?

I wondered that too.
I hadn't looked at the contents of that pkg before, but now I see that it (and the MacOSX10.4.Universal.pkg) are actually badly named - they actually are part of the developers tools (supplying the libraries used when targeting other OS X versions than the one on the development system).
They only install stuff under /Developer:

In thinking about this a bit more, I have what I think is a reasonable guess/explanation for the difference. The computer in question is a PCI-express PowerMac G5 dual core 2 GHz. This computer was released after Tiger had been out for awhile, so the original install of OS X on this computer did not use a retail Tiger DVD.

It was initially shipped with a special build of 10.4.2?, if memory serves. Possibly the build shipped from Apple with the then-new hardware had slightly later compile dates for items than the compile dates of the stock Tiger build?

Trevor

That sounds like a very probable explanation.

It's astonishing that Apple will release such builds that seem to be from another branch than the stable distribution.

I'll keep that in mind when debugging in the future:
There could be different binaries on seemingly identical OS versions.

They just did it again with a custom build of 10.4.7 for the Mac Pro and that version even has an extra SecUpdate different from the main build...

Hopefully they'll be able to keep track of all these different builds, it could be really nasty to debug when you try to reproduce a problem on another machine, assuming they use identical OS components when they do not.