2081887 - Hang in exception handler thread due to dyld calling malloc

Status: NEW

(Toolkit :: Crash Reporting, defect)

Description

[(not currently active) Ted Mielczarek]

Attachment: Hang report from macOS

I had Firefox hang on my work laptop (MacBook M4 Pro, Mac16,8, Tahoe 26.6.2) and the macOS-generated hang report (attached) seems to indicate that there's a deadlock with the exception handler thread calling into dyld which is calling malloc, which is stuck waiting for the malloc lock. Here's an excerpt from the hang report with just that thread:

  Thread 0x2d37d28    Thread name "Breakpad ExceptionHandler"    10 samples (1-10)    priority 31 (base 31)    cpu time <0.001s (78.3K cycles, 32.7K instructions, 2.40c/i, 3.74GHz avg)
  <process frontmost, thread QoS default (requested default), process unclamped, jetsam priority 100 (requested 100, assertion 0), process memory limit 0MB, process received importance donation from runningboardd [600], process received importance donation from WindowServer [601], process received importance donation from distnoted [925], process received importance donation from CursorUIViewService [1322], IO tier 0>
  10  thread_start + 8 (libsystem_pthread.dylib + 7196) [0x183446c1c] 1-10
    10  _pthread_start + 136 (libsystem_pthread.dylib + 27736) [0x18344bc58] 1-10
      10  ??? (XUL + 22190204) [0x14032d87c] 1-10
        10  ??? (XUL + 90952288) [0x1444c1260] 1-10
          10  ??? (XUL + 90926020) [0x1444babc4] 1-10
            10  ??? (XUL + 90926744) [0x1444bae98] 1-10
              10  ??? (XUL + 3821520) [0x13f1a8fd0] 1-10
                10  _tlv_get_addr + 104 (libdyld.dylib + 119792) [0x1830483f0] 1-10
                  10  dyld::ThreadLocalVariables::instantiateVariable(dyld::ThreadLocalVariables::Thunk const&) + 56 (libdyld.dylib + 122716) [0x183048f5c] 1-10
                    10  _malloc_type_malloc_outlined + 96 (libsystem_malloc.dylib + 124612) [0x18325b6c4] 1-10
                      10  _malloc_zone_malloc_instrumented_or_legacy + 152 (libsystem_malloc.dylib + 238076) [0x1832771fc] 1-10
                        10  malloc + 232 (libmozglue.dylib + 40440) [0x102639df8] 1-10
                          10  __ulock_wait2 + 8 (libsystem_kernel.dylib + 60568) [0x183415c98] 1-10
                           *7   ??? (kernel.release.t6041 + 6548920) [0xfffffe000bd82db8] (blocked by turnstile with priority 61 waiting for firefox (Firefox) [76705] [unique pid 14778326] thread 0x2d37bc2) 1-7
  <process non-frontmost>
                           *3   ??? (kernel.release.t6041 + 6548920) [0xfffffe000bd82db8] (blocked by turnstile with priority 61 waiting for firefox (Firefox) [76705] [unique pid 14778326] thread 0x2d37bc2) 8-10

Thread 0x2d37bc2 mentioned in the last two frames is the main thread, which I assume has crashed.

Comment 1

[(not currently active) Ted Mielczarek]

I'm laughing at one of the suggested similar bugs being bug 848075, which I both filed and fixed ages ago.

Comment 2

[Sylvestre Ledru [:Sylvestre]]

You have to come back to fix it Ted ;)

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I was curious, so I downloaded a build of 157.0.1 and looked at offset 3821520, the frame before _tlv_get_addr. The problem appears to be nsID::GenerateUUIDInPlace → GenerateRandomBytesFromNSS → NS_IsMainThread (for the first time on this thread, maybe?) → read sTLSIsMainThread → dyld malloc'ing space for thread-local storage. I'll speculate that this is a regression from bug 1993525, which added the one GenerateUUID call I'm seeing in toolkit/crashreporter.

Comment 4

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1993525

:afranchuk, since you are the author of the regressor, bug 1993525, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.