On OS X, what's a double panic?

Can anyone offer a relatively simple explanation of how a double panic differs from other types of kernel panic on a Mac?

Simple as in … I'm not a developer, but I wish to understand these things a little better.

Background

A loose description of panics of this type:

• the phrase "double panic" on screen at the time of the panic

• if there is a .panic file, it'll not include that phrase

• sometimes there's no .panic file, which might explain why I can find only limited discussion of double panics.

An OS X 10.8.5 example

Screenshots below will also relate to a topic in the ZEVO area – I'll continue the support discussion there in due course.

Safari in front:

In the background, installation of Ubuntu 12.10 to a VirtualBoxVM:

In the background, Activity Monitor:

Running in the Dock: Finder, Activity Monitor, AntiRSI …

… Mail, Safari, Terminal, VirtualBox and VirtualBoxVM:

Nine swap files:

VirtualBoxVM writing to a virtual disk:

(Side note: with my very old but lovely iPhone, I couldn't get better photographs.)

---

Found

What causes a kernel trap 0x00000008 (SCO Unix) (2005?) mentions:

… the Double Panic- the kernel panics while panicing.

It can be caused by corrupt driver code, but is more likely to be bad ram (or bad CPU, motherboard- anything that causes a bad instruction to get to the cpu)

– but the heading there is:

This is an ancient post with little relevance to modern systems.

I could find no up-to-date authoritative generic explanation.

Note

In irc://chat.freenode.net/#macdev on 2013-09-25 in response to an earlier edition of this question, someone stated that it's clearly:

• a panic during a panic.

This is quite simply a safety mechanism in the kernel panic code to stop dumping more information to the screen when the code to attempt to save system state also has crashed.

We can inspect the source code for xnu in OS X 10.8.4 and see the relevant handling:

http://www.opensource.apple.com/source/xnu/xnu-2050.24.15/osfmk/kern/debug.c

restart:
    PANIC_LOCK();

    if (panicstr) {
        if (cpu_number() != paniccpu) {
            PANIC_UNLOCK();
            /*
             * Wait until message has been printed to identify correct
             * cpu that made the first panic.
             */
            while (panicwait)
                continue;
            goto restart;
        } else {
            nestedpanic +=1;
            PANIC_UNLOCK();
            Debugger("double panic");
            printf("double panic:  We are hanging here...\n");
            panic_stop();
            /* NOTREACHED */
        }
    }

As you can see, several CPU could also raise a panic and both those signals would need to be resolved by the same code - so that's possibly a more likely vector to see the double panic message.

Also model_dep.c and kmod.c have helpful code and comments to explain how the system tries to avoid double panics just due to running on more than one CPU.

In practice, all panic information is suspect, and double panic information is doubly suspect unless you can reproduce the issue or correlate several dumps.