403467 - Regular Kernal Panics on Core Duo, fixed by deleting Camino Cache

Status: VERIFIED INVALID

(Camino Graveyard :: General, defect)

Description

[R Entwisle]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.6) Gecko/20070809 Camino/1.5.1 (MultiLang)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.6) Gecko/20070809 Camino/1.5.1 (MultiLang)

Regular reliable Kernal Panics. Recreatable. This has been hapening for months on my 17" MacBook Pro. The Kernal Panics happen after several weeks of constant use. The Kernal Panics are random, but once they start they happen two or three times a day. Camino only has to be open to trigger the problem. It can be the foreground program or an untouched background process. The quick and dirty solution is to go to user/library/caches/Camino/ and delete the cache folder. This brings stability up to 100% for the next few weeks.

Reproducible: Always

Steps to Reproduce:
1.Run Camino as a foreground or background program without closing often.
2.Happily run Camino for the next three weeks.
3.Watch as the kernal panic happens while I am using Camino, or another program with Camino running as a background process.
Actual Results:  
Kernel Panic two or three times per day once Camino has reached the unstable point.

Expected Results:  
No crashy crashy

Model MacBookPro1,2 Core Duo 2.16 GHz, 2GB RAM, ROM version MBP12.0061.B03, SMC Version 1.5f10

I suspect this could be caused by the unusual hardware. Not that many core duo MBP machines in circulation.

Comment 1

[R Entwisle]

OSX 10.4.10

Comment 2

[Stuart Morgan]

While Camino may somehow be part of the trigger of kernel panics on your machine, Camino is entirely a user-land process, and it's therefore impossible, by definition, for Camino to be the cause of the panics, so closing.

Whatever the apparent trigger, a kernel panic is either an Apple bug or a bug in something third-party that is running in kernel space (e.g., another user with kernel panics that were apparently caused by Camino eventually tracked it down to buggy kernel-level popup blocking software).

Comment 3

[R Entwisle]

This is the sort of response that gives bug reporting on Mozilla a bad reputation.

This has been triggered three times with no other processes running. No background processes. Absolutely no programs are run on this system to alter OSX or enhance anything including program launchers. While it could be OSX, it has happened on 10.4.9 and 10.4.10.

I originally believed that the program causing these kernel panics was Azureus as it was always running when they happened, and Camino had been stable for me for years. I switched off Azureus and ALL other software for a day and had three crashes. Do not assume that all end users are incapable of tracking down a bug.

Comment 4

[R Entwisle]

One last comment, I even realised from the start that this could be a hardware problem. The first thing I did was to clean the system caches and run the system for 36 hours clean with no processes. No kernel panics. I believed I had resolved the problem. Until four hours after starting all my software up, including Azureus and Camino. All other possibilities HAVE been excluded. The Kernal Panics have been tracked down to Camino, or the way it interacts with OSX.

Comment 5

[Stuart Morgan]

(In reply to comment #3)
> Do not assume that all end users are incapable of tracking down a bug.

That's not at all what I said, and I'm sorry that you felt that my response was unreasonable. It's not that I have any doubt in your ability to determine the trigger of your panics, it's that the trigger of a panic and the cause of a panic are not necessarily the same thing, and in the case of Camino, which is entirely user-land, it cannot be. Please understand that the designation of "INVALID" isn't any kind of commentary on whether or not the problem is in fact real, or serious for you, but simply the way we close bugs that aren't bugs in Camino itself, and thus can't be meaningfully tracked within our bug reporting system.

In this case, it sounds like you have a perfectly valid bug to file with Apple--again, *by definition*, a kernel panic, even when triggered by a user-land process, is a bug in the kernel. I'm not saying this as a knee-jerk attempt to shift blame; I used to work at Apple, in a group that was, among other things, responsible for stress-testing low-level system components. A kernel panic is a kernel bug (or a bug in a kernel extension), whatever the trigger. We don't have the option of not using the OS, so there's nothing that we can do about this.

I'd recommend filing this with Apple at bugreport.apple.com, as Apple is the only party capable of fixing this issue.