Handler not exiting sometimes on macOS

Matt Galloway

unread,

Jan 17, 2021, 4:58:21 AM1/17/21

to Crashpad-dev

We have Crashpad integrated into our app for macOS and Windows. All seems to work just fine except for occasionally we see on macOS that the handler process doesn't terminate when the application quits.

I haven't yet managed to find out under what circumstances that happens - it all seems quite random so far. So I'm posting here to see if anybody has thoughts on how to debug this or if it's something other people see?

This is a sample of the handler process's main thread once it's stuck:

2791 Thread_3613628 DispatchQueue_1: com.apple.main-thread (serial)

+ 2791 start (in libdyld.dylib) + 1 [0x7fff6c49bcc9]

+ 2791 crashpad::HandlerMain(int, char**, std::__1::vector<std::__1::unique_ptr<crashpad::UserStreamDataSource, std::__1::default_delete<crashpad::UserStreamDataSource> >, std::__1::allocator<std::__1::unique_ptr<crashpad::UserStreamDataSource, std::__1::default_delete<crashpad::UserStreamDataSource> > > > const*) (in crashpad_handler) + 2996 [0x10e334674]

+ 2791 crashpad::ExceptionHandlerServer::Run(crashpad::UniversalMachExcServer::Interface*) (in crashpad_handler) + 703 [0x10e333157]

+ 2791 crashpad::MachMessageServer::Run(crashpad::MachMessageServer::Interface*, unsigned int, int, crashpad::MachMessageServer::Persistent, crashpad::MachMessageServer::ReceiveLarge, unsigned int) (in crashpad_handler) + 289 [0x10e368e91]

+ 2791 crashpad::(anonymous namespace)::MachMessageAllocateReceive(crashpad::(anonymous namespace)::MachMessageBuffer*, int, unsigned int, unsigned int, unsigned long long, unsigned int, bool) (in crashpad_handler) + 95 [0x10e3690f8]

+ 2791 crashpad::MachMessageWithDeadline(mach_msg_header_t*, int, unsigned int, unsigned int, unsigned long long, unsigned int, bool) (in crashpad_handler) + 148 [0x10e3689a9]

+ 2791 crashpad::(anonymous namespace)::MachMessageWithDeadlineInternal(mach_msg_header_t*, int, unsigned int, unsigned int, unsigned long long, unsigned int, bool) (in crashpad_handler) + 200 [0x10e368a8e]

+ 2791 mach_msg (in libsystem_kernel.dylib) + 60 [0x7fff6c5dd170]

+ 2791 mach_msg_trap (in libsystem_kernel.dylib) + 10 [0x7fff6c5dcdfa]

This looks like what I'd expect if the handler was sitting there waiting for a crash or the process to exit. And I'm guessing this is going to be something along the lines of MACH_NOTIFY_NO_SENDERS not being sent, or filtered out for some reason. But why?

We have not altered the Crashpad code in any way at all.

Does anybody have any suggestions here of why this might be happening?

Regards,

Matt Galloway

Joshua Peraza

unread,

Jan 19, 2021, 3:03:24 PM1/19/21

to Matt Galloway, Crashpad-dev

If your application has launched any helper processes, they will inherit your application's relationship to crashpad_handler. If those helper processes are still hanging around, crashpad_handler might be waiting for them to exit.

--
You received this message because you are subscribed to the Google Groups "Crashpad-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crashpad-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crashpad-dev/8ae51c5d-df07-415f-8bc1-e3438faf415dn%40chromium.org.

Mark Mentovai

unread,

Jan 19, 2021, 3:38:56 PM1/19/21

to Joshua Peraza, Matt Galloway, Crashpad-dev

lsmp may be able to help diagnose what's connected to crashpad_handler.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crashpad-dev/CAFRSFxKHgB7MO-CgrFpOjjvwDiwP0wLmNshKmt9RC6r%3D-D__Ow%40mail.gmail.com.

Matt Galloway

unread,

Feb 11, 2021, 11:56:25 AM2/11/21

to Mark Mentovai, Joshua Peraza, Crashpad-dev

lsmp may be able to help diagnose what's connected to crashpad_handler.

The `lsmp` suggestion is great. I finally managed to get it to happen again - unsure why it got into this state, but this is what `lsmp` shows:

```

name ipc-object rights flags boost reqs recv send sonce oref qlimit msgcount context identifier type

--------- ---------- ---------- -------- ----- ---- ----- ----- ----- ---- ------ -------- ------------------ ----------- ------------

0x00000103 0x71c06aaf send -------- --- 2 0x00000000 TASK SELF (78148) crashpad_handler

0x00000203 0x71c081a7 recv -------- 0 --- 1 N 5 0 0x0000000000000000

0x00000307 0x71c064c7 send -------- --- 1 0x00000000 THREAD (0x1f3c65a)

0x00000403 0x71c08057 recv -------- 0 --- 1 N 5 0 0x0000000000000000

0x00000503 0x71c075d7 recv -------- 0 --- 1 N 5 0 0x0000000000000000

0x00000607 0x71c06767 recv -------- 0 --- 1 N 5 0 0x0000000000000000

0x00000707 0x1292b8df send -------- --- 4 -> 128 0 0x0000000000000000 0x0003d003 (1) launchd

0x00000803 0x02b805d7 send -------- --- 1 0x00000000 CLOCK

0x00000903 0x71c082f7 send -------- --- 1 0x00000000 SEMAPHORE

0x00000a03 0x71c088df send -------- --- 1 0x00000000 THREAD (0x1f3c65a)

0x00000b03 0x71c06bff send -------- --- 1 0x00000000 SEMAPHORE

0x00000c03 0x71c05edf recv,send -------- 0 --- 1 1 Y 5 0 0x0000000000000000

0x00000d03 0x02b7fe9f send -------- --- 1 0x00000000 HOST

0x00000e03 0x04a8180f send -------- --- 1 0x00000000 VOUCHER

0x00000f07 0x71c0641f recv -------- 0 --- 1 1 N 5 0 0x0000000000000000

0x00001007 0x0d888a6f send -------- --- 1 -> 6 0 0x0000000000000000 0x00001103 (209) coreservicesd

0x00001103 0x1ffc578f recv -------- 0 -NP 1 Y 5 0 0x0000000000000000

+ send -------- --- 1 <- 0x00048b57 (8711) lsmp

0x00001203 0x71c073df recv -------- 0 --- 1 N 5 0 0x0000000000000000

0x00001303 0x71c06ca7 send -------- --- 1 0x00000000 THREAD (0x1f3c65a)

0x00001403 0x71c06b57 recv,send ---GS--- 0 --- 1 2 Y 5 0 0x0000000000000000

0x00001503 0x71c07487 recv,send -------- 0 --- 1 1 Y 5 0 0x0000000000000000

0x00001603 0x71c07c67 send -------- --- 1 0x00000000 THREAD (0x1f3c65a)

0x00001703 0xc3de2487 recv ---GS--- 0 --- 1 1 N 5 0 0x0000000000000000

0x00001803 0x23f9b967 port-set -------- --- 1 2 members

- 0x71c0641f recv -------- 0 --- 1 1 N 5 0 0x0000000000000000 0x00000f07 (78148) crashpad_handler

- 0x1ffc578f recv -------- 0 -NP 1 Y 5 0 0x0000000000000000 0x00001103 (78148) crashpad_handler

0x00001903 0xc3de2b17 send -------- --- 1 0x00000000 SEMAPHORE

0x00001a03 0x04a823df send -------- --- 1 -> 32 0 0x0000000000000000 0x00001103 (203) notifyd

0x00001b03 0x1b23fd4f recv ---GS--- 0 --- 1 Y 16 0 0x0000000000000000

+ send -------- D-- 2 <- 0x00017aaf (203) notifyd

0x00001c03 0x1b23eaef send -------- --- 1 -> 1 0 0x0000000000000000 0x00069e17 (146) logd

0x00002303 0x1b23f41f send -------- --- 1 -> 1 0 0x0000000000000000 0x0006892f (146) logd

0x00002503 0x1b24028f recv,send ---GS--- 0 --- 1 1 Y 5 0 0x0000000000000000

+ send -------- --- 1 <- 0x0006126b (146) logd

0x00002603 0x04a80e37 send -------- --- 1 -> 6 0 0x0000000000000000 0x00000903 (146) logd

0x00002703 0x1b24163f recv,send -------- 0 --- 1 1 Y 5 0 0x0000000000000000

0x00002803 0x104708b7 send -------- D-- 1 -> 5 0 0x0000000000000000 0x00003e1b (209) coreservicesd

0x00002903 0x71c06df7 recv -------- 0 --- 1 N 5 0 0x0000000000000000

total = 34

SEND = 23

RECEIVE = 15

SEND_ONCE = 0

PORT_SET = 1

DEAD_NAME = 0

DNREQUEST = 1

VOUCHERS = 1

Thread_KObject Thread-ID Port Description.

```

I'm a bit at a loss for how to interpret this - so if anybody has ideas, I'm all ears!

Regards,

Matt Galloway

--

Matt Galloway
m: +44 7533 572204
e: ma...@galloway.me.uk
w: http://www.galloway.me.uk/

Check out my book - Effective Objective-C 2.0 - http://bit.ly/EffObjC3

Reply all

Reply to author

Forward