I'm trying to run make check in debug mode on Mac 10.6 with clang, I see this: Assertion failure: OnLionOrLater() || gCriticalAddress.mAddr != NULL If I run it in compiled with gcc I get no assertions. Commenting out the line on clang runs successfully.

This blocks a switch to clang, not enabling leak tests on gcc built binaries. I will debug this.

This was the mozconfig I used for compiling TB.

I have not been able to reproduce this on m-c. What repository are you using? what revision?

Sorry, I am having a hard time reproducing this. I have built the same version of clang on 10.6 and tried you exact mozconfig on comm-central (cd77f678aa1c). The only failures I got from make check were from bug529130.js complaining about too much recursion, which I believe is because clang -O0 produces binaries that use a lot of stack space.

This fixes the case of a 64 bit OS X without unwind.h.

Comment on attachment 579197 [details] [diff] [review] Only try to init the critical range if we are able to walk the stack This patch does not fix the crash for me. The real issue, as far as I can tell, is that the set of conditions for this code to be compiled is different with the set of conditions for a useful implementation of NS_StackWalk to be compiled.

Note that OnLionOrLater is not on the .ii file. If you are still seeing an assert with it, we are missing a dependency somewhere.

Comment on attachment 579197 [details] [diff] [review] Only try to init the critical range if we are able to walk the stack I don't know what was happening last time that I tried this, but this is definitely fixing the crashes. So, r=me.

Comment on attachment 579197 [details] [diff] [review] Only try to init the critical range if we are able to walk the stack This is now biting me on the mozilla-esr10 branch, can we backport it there as well? The fix has been shipped in 11 already.

Comment on attachment 579197 [details] [diff] [review] Only try to init the critical range if we are able to walk the stack [triage comment] esr branch is strictly production and afaik no one should be doing clang builds here, please re-nom if there's a case for how this affects the user or production builds.