Daily Kernel Panics....Are Apple hiding something?

Question

Guys,
I am getting kernel Panics on almost a daily basis now and i have been following this thread http://discussions.apple.com/thread.jspa?threadID=459270&tstart=45
But someone has locked it. Why? Do Apple not want us talking about these things?
I am getting really annoyed at these panics, it can't be bad ram as i have had 2 other MBP's with the same RAM in and never got the panics.
Can you help by looking at these logs?
Tue May 2 16:50:42 2006
panic(cpu 0 caller 0x0034FBE6): mbuf address out of range 0x2c4208
Backtrace, Format - Frame : Return Address (4 potential args on stack)
0x24d4bb04 : 0x128b5e (0x3bbeb8 0x24d4bb28 0x131bbc 0x0)
0x24d4bb44 : 0x34fbe6 (0x3db914 0x2c4208 0x156ec68 0x13f5f5)
0x24d4bb64 : 0x22e673 (0x1 0x2 0x24d4bb74 0x18)
0x24d4bc44 : 0x22d460 (0x5a62540 0x34 0x1 0x201000a)
0x24d4be14 : 0x222007 (0x36bba300 0x14 0x24d4bf14 0x965506)
0x24d4be54 : 0x223a8b (0x36bba300 0x14 0x6 0x0)
0x24d4bf64 : 0x211109 (0x36bba300 0x36bba300 0x42cb5c 0x135798)
0x24d4bfa4 : 0x1f773d (0x3ac3404 0x36bba300 0x36b8901a 0x1)
0x24d4bfd4 : 0x197a21 (0x0 0x0 0x358d318 0x134aec) Backtrace terminated-invalid frame pointer 0x0
Kernel version:
Darwin Kernel Version 8.6.1: Tue Mar 7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386
Thu May 4 17:14:58 2006
panic(cpu 0 caller 0x0034FBE6): mbuf address out of range 0x2c4208
Backtrace, Format - Frame : Return Address (4 potential args on stack)
0x24e13b04 : 0x128b5e (0x3bbeb8 0x24e13b28 0x131bbc 0x0)
0x24e13b44 : 0x34fbe6 (0x3db914 0x2c4208 0x156ec68 0x36a6003c)
0x24e13b64 : 0x22e673 (0x1 0x2 0x18 0x18)
0x24e13c44 : 0x22d460 (0x3e9fe88 0x34 0x1 0x201000a)
0x24e13e14 : 0x222007 (0x36be2b00 0x14 0x24e13f14 0x968506)
0x24e13e54 : 0x223a8b (0x36be2b00 0x14 0x6 0x0)
0x24e13f64 : 0x211109 (0x36be2b00 0x36be2b00 0x42cb5c 0x135798)
0x24e13fa4 : 0x1f773d (0x3b61e04 0x36be2b00 0x36a6001a 0x1)
0x24e13fd4 : 0x197a21 (0x0 0x0 0x358d318 0x3a80c000) Backtrace terminated-invalid frame pointer 0x0
Kernel version:
Darwin Kernel Version 8.6.1: Tue Mar 7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386
Mon May 8 18:55:54 2006
panic(cpu 1 caller 0x0034FBE6): mbuf address out of range 0x2c4208
Backtrace, Format - Frame : Return Address (4 potential args on stack)
0x2569bbd8 : 0x128b5e (0x3bbeb8 0x2569bbfc 0x131bbc 0x0)
0x2569bc18 : 0x34fbe6 (0x3db914 0x2c4208 0x2569bc38 0x198b25)
0x2569bc38 : 0x22e673 (0x1 0x2 0x5a8 0x46ad7f8)
0x2569bd18 : 0x23126d (0x47a6858 0x0 0x3552bd 0x2569bebc)
0x2569bd38 : 0x35561b (0x47a6630 0x0 0x2569bebc 0x13572c)
0x2569bdf8 : 0x346cb5 (0x47a6630 0x0 0x2569bebc 0x0)
0x2569be28 : 0x3427e0 (0x4804a50 0x2569bebc 0x47bf504 0x0)
0x2569bf18 : 0x3429f9 (0x42941f4 0x4804a50 0x1b 0x15f7a075)
0x2569bf78 : 0x36d8e4 (0x42941f4 0x476b004 0x476b048 0x0)
0x2569bfd8 : 0x197e7e (0x4b38f90 0x4b38f90 0x359e9000 0x2569bd24) No mapping exists for frame pointer
Backtrace terminated-invalid frame pointer 0xb0b1f2a8
Kernel version:
Darwin Kernel Version 8.6.1: Tue Mar 7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386
Thu May 11 16:07:51 2006
panic(cpu 0 caller 0x0034FBE6): mbuf address out of range 0x2c4208
Backtrace, Format - Frame : Return Address (4 potential args on stack)
0x24d43b04 : 0x128b5e (0x3bbeb8 0x24d43b28 0x131bbc 0x0)
0x24d43b44 : 0x34fbe6 (0x3db914 0x2c4208 0x1544c68 0x13f5f5)
0x24d43b64 : 0x22e673 (0x1 0x2 0x24d43b74 0x18)
0x24d43c44 : 0x22d460 (0x42ff228 0x34 0x1 0x201000a)
0x24d43e14 : 0x222007 (0x368c3200 0x14 0x24d43f14 0x949506)
0x24d43e54 : 0x223a8b (0x368c3200 0x14 0x6 0x0)
0x24d43f64 : 0x211109 (0x368c3200 0x368c3200 0x42cb5c 0x135798)
0x24d43fa4 : 0x1f773d (0x3a8d804 0x368c3200 0x368e781a 0x1)
0x24d43fd4 : 0x197a21 (0x0 0x0 0x3562278 0x34fe2000) Backtrace terminated-invalid frame pointer 0x0
Kernel version:
Darwin Kernel Version 8.6.1: Tue Mar 7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386

Answer 1

Hmm. Well unless Mac OS X does things in a completely different way to other unix platforms I've used, it looks like its impossible to tell where the problem is from the stack trace as the kernel appears to have been built with the symbol table stripped out. That's why you're just getting addresses and not the names of functions. Not a very useful thing to do really. I can't tell for sure though as the file(1) command on OSX doesn't seem to report this (stripped/not stripped) either. Also not a very useful thing to do.
I concur with others on this thread that if you've moved the same RAM between 3 systems now, that you might have statically damaged it on the 3rd attempt. You have been using anti-static straps haven't you ???
What about putting the original memory back into the system and running it with that to see if the problem happens again?
Having said that, there's also a chance this isn't memory. Something is trashing memory pointers, yes. But the panic string is suspiciously consistent. It could be either be a buggy device driver, or 3rd party kernel extensions, or some other hardware component on the system that's playing up and feeding the kernel a garbage memory address.
If Apple's hardware tests (described elsewhere in this thread) can't find the problem, tracking this down would be a nightmare, as the memory address causing the panic could get corrupted much earlier and take some time to bubble to the surface. All depends on system usage. The only way to find a problem like that would be for Apple to first custom build you a kernel with the symbol table so they could examine the stack in more detail. And then build further custom instrumented kernels that back track and log where addresses are coming from. It could take several iterations of this process before they found the culprit. It's NOT an easy thing to do. And I don't know if they would even do such a thing unless you're a big corporate account as its very expensive in engineering time to do it. Would be cheaper for them to just give you a new one.
My advice: Run the hardware tests and hope it turns up a bad memory dimm. If it doesn't find anything, return it and get a replacement. If you swap the system and afterwards re-use the same memory for a 4th time, and it does the same thing again, it's your memory that's the problem. Buy another memory dimm and try using it in combination with the other two to eliminate the problem.