Cameron Kaiser

Those terminal assertions are really scary. I've never seen them before. Can you rebuild without `--enable-optimize` and see what the backtrace looks like? I don't know why `gdb7` isn't reading...

Odd, I thought I put the binary in -4 as well. Here it is. [gdb7.gz](https://github.com/classilla/tenfourfox/files/1637657/gdb7.gz)

That's a bit alarming on its own, but how about changing to `--enable-optimize=-Og` as a middle ground? Does that help at all?

This means there's an optimization issue. Does compiling `--enable-optimize=-O1` or `-O2` also work?

I think the next thing to do is make this assert fatal, since this is the earliest point we can predictably see it goes wrong: ``` [8932] ###!!! ASSERTION: Double-initing...

I'm sceptical of that backtrace. Can you give the the debugger's view with `bt`? The XPCOM backtrace is sometimes bad at resolving symbols.

Alternatively, after the `NS_PRECONDITION` I guess we could just do `MOZ_ASSERT(0)` and _make_ it crash.

I'm not sure this is the same assertion. Does it always terminate with the `mRawPtr` one? I'm surprised the `NS_PRECONDITION` fires but not `MOZ_ASSERT` (though right now the compiler's sanity...

That backtrace makes sense to me given the symptoms reported (it's a failure to handle the XUL for the window), but I'm not sure why it's gone wrong and the...

That seems reasonable as far as the optimization options, but I'd still stick with the DEBUG configuration because it might crash with a different error and you'd be rebuilding DEBUG...