1376142 - Whole Firefox crash in OS X without crash Report

Status: NEW

(Core :: Widget: Cocoa, defect, P5)

Description

[Safwan Rahman (:safwan)]

Attachment: error.log

Hi,
So my whole nightly get crashed and exit. I get some Crash report from the OS X crash reporter, but no crash report in about:crashes.
The debug log is attached

Comment 1

[Ciprian Muresan [:cmuresan], Formerly of Ecosystem QA - please needinfo @mcoman for things regarding the team]

Hi Safwan,

We need a bit more information to make this issue actionable. What were you doing before the browser crashed? How many tabs did you have open? Do you have add-ons installed, if yes, can you please provide a list of them? Was this a one time thing or does this constantly happen to you? If the latter, is the reproducible in safe mode?

Comment 2

[Safwan Rahman (:safwan)]

What were you doing before the browser crashed?
> I was just browsing in Facebook while it crashed

How many tabs did you have open?
> I had about 12 tabs open at that time

Do you have add-ons installed, if yes, can you please provide a list of them?
> Yes. I have a some add-ons installed. I am attaching a file of "about-support" data where you can find all the add-ons I have installed

Was this a one time thing or does this constantly happen to you?
> It happens before, but I did not consider as it happened only one time. But later I thought this should be informed


I can not reproduce it anyhow actually. If it happen next, I will try to reproduce it again

Comment 3

[Safwan Rahman (:safwan)]

Attachment: about-support data

Comment 4

[Ciprian Muresan [:cmuresan], Formerly of Ecosystem QA - please needinfo @mcoman for things regarding the team]

User Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID  20170712100330

I've tried several times to reproduce the issue on Nightlies from the last few days. But I have not been able to make the browser crash.

Markus, could you please take a look at the attached crash log and see if anything pops out in order to help us understand what's happening?

Comment 5

[Markus Stange [:mstange]]

So it's crashing in the NSEventThread with this stack:

Thread 30 Crashed:: com.apple.NSEventThread
0   com.apple.CoreFoundation      	0x00007fffb90dc95b __CFRunLoopServiceMachPort + 443
1   com.apple.CoreFoundation      	0x00007fffb90dbcf1 __CFRunLoopRun + 1361
2   com.apple.CoreFoundation      	0x00007fffb90db544 CFRunLoopRunSpecific + 420
3   com.apple.AppKit              	0x00007fffb6d21f02 _NSEventThread + 205
4   libsystem_pthread.dylib       	0x00007fffceea293b _pthread_body + 180
5   libsystem_pthread.dylib       	0x00007fffceea2887 _pthread_start + 286
6   libsystem_pthread.dylib       	0x00007fffceea208d thread_start + 13

... which indicates that the thread is completely idle.

It crashes with

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000002, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Trace/BPT trap: 5
Termination Reason:    Namespace SIGNAL, Code 0x5
Terminating Process:   exc handler [0]

which, to me, indicates that __CFRunLoopServiceMachPort itself raised a breakpoint for some reason.

The relative offset into the CoreFoundation library (architecture x86_64) of the crashing address is 0x8595B.

Around that address, the assembly looks like this:

                     loc_8595a:
000000000008595a         int3                                                   ; CODE XREF=sub_85800+274
                        ; endp
000000000008595b         call       imp___stubs__getpid

Hopper gives me the following pseudo code for the method:

> int ___CFRunLoopServiceMachPort(int arg0, int arg1, int arg2, int arg3, int arg4, int arg5) {
>     rcx = arg3;
>     rdi = arg0;
>     var_30 = arg5;
>     var_40 = arg4;
>     var_50 = arg2;
>     r13 = arg1;
>     var_34 = rdi;
>     r15 = *r13;
>     rdx = 0x6;
>     if (arg4 != 0x0) {
>             rdx = 0x806;
>     }
>     r12 = 0x7000000;
>     if (rcx != 0xffffffff) {
>             r12 = 0x7000100;
>     }
>     r12 = r12 | rdx;
>     *(int32_t *)r15 = 0x0;
>     *(int32_t *)(r15 + 0xc) = rdi;
>     *(int32_t *)(r15 + 0x8) = 0x0;
>     *(int32_t *)(r15 + 0x4) = 0xc00;
>     *(int32_t *)(r15 + 0x14) = 0x0;
>     rbx = rcx;
>     r14 = mach_msg(r15, r12, 0x0, *(int32_t *)(r15 + 0x4), var_34, rbx, 0x0);
>     voucher_mach_msg_revert(*var_40);
>     rax = voucher_mach_msg_adopt(r15);
>     *var_40 = rax;
>     if (var_30 != 0x0) {
>             if (rax != 0xffffffffffffffff) {
>                     *var_30 = voucher_copy();
>             }
>             else {
>                     *var_30 = 0x0;
>             }
>     }
>     if (sign_extend_64(r14) != 0x10004004) goto loc_85906;
> 
> loc_858ce:
>     if (0x1 != 0x0) {
>             *r13 = 0x0;
>             rax = sub_85800();
>     }
>     else {
>             rax = sub_85800();
>     }
>     return rax;
> 
> loc_85906:
>     if (r14 == 0x10004003) goto loc_85927;
> 
> loc_8590f:
>     if (r14 != 0x0) goto loc_8595a;
> 
> loc_85914:
>     rax = 0x1;
>     rcx = 0x0;
>     rdx = var_50;
>     if (r15 != 0x0) {
>             rcx = *(int32_t *)(r15 + 0xc);
>     }
>     goto loc_85946;
> 
> loc_85946:
>     *(int32_t *)rdx = rcx;
>     rax = rax & 0xff;
>     return rax;
> 
> loc_8595a:
>     asm { int3 };
>     rax = loc_8595b();
>     return rax;
> 
> loc_85927:
>     if (0x1 == 0x0) {
>             free(r15);
>     }
>     *r13 = 0x0;
>     rcx = 0x0;
>     rax = 0x0;
>     rdx = var_50;
>     goto loc_85946;
> }

We jump to the asm { int3 } line if r14 != 0x0, which probably means ret != MACH_MSG_SUCCESS, if you compare it to the possibly outdated source code at https://github.com/opensource-apple/CF/blob/3cc41a76b1491f50813e28a4ec09954ffa359e6f/CFRunLoop.c#L2231 .

I think this means that we're hitting the HALT; line at https://github.com/opensource-apple/CF/blob/3cc41a76b1491f50813e28a4ec09954ffa359e6f/CFRunLoop.c#L2248

And we're hitting it because we got a value from the system that indicates an error.

It seems unlikely that this crash was the fault of Firefox.

Comment 6

[Markus Stange [:mstange]]

Does the crash reporter not catch int3 breakpoint crashes?

Comment 7

[Mike Hommey [:glandium]]

(In reply to Markus Stange [:mstange] from comment #6)
> Does the crash reporter not catch int3 breakpoint crashes?

It seems like we don't set a signal handler for SIGTRAP (and if we added that, that might have side effects on XPCOM_DEBUG_BREAK=trap and nsIDebug2::break())